Configurar um Dev Drive no Windows 11

O Dev Drive é uma nova forma de volume de armazenamento disponível para melhorar o desempenho das principais cargas de trabalho do desenvolvedor.

O Dev Drive baseia-se na tecnologia ReFS para empregar otimizações específicas do sistema de arquivos e proporcionar mais controlo sobre as configurações dos volumes de armazenamento e segurança, incluindo atribuição de confiança, configuração de antivírus e controlo administrativo sobre quais filtros estão aplicados.

Consulte a postagem do blog: Dev Drive for Performance Improvements in Visual Studio and Dev Boxes para obter algumas medições de melhoria média em operações de desenvolvimento comuns.

Como configurar um Dev Drive

Para configurar uma nova Unidade de Desenvolvimento, abra as Configurações do Windows e navegue até Sistema>Armazenamento>Configurações Avançadas de Armazenamento>Discos e volumes. Selecione Criar unidade de desenvolvimento. Os volumes de armazenamento existentes não podem ser convertidos em uma unidade de desenvolvimento. A designação Dev Drive acontece apenas no momento da formatação original.

Antes de configurar uma unidade de desenvolvimento, verifique se os pré-requisitos estão cumpridos.

>

Pré-requisitos

• Windows 11, Build #10.0.22621.2338 ou posterior (Verifique se há atualizações do Windows)
• Recomendar 16 GB de memória (mínimo de 8 GB)
• Mínimo de 50 GB de espaço livre em disco
• Os Dev Drives estão disponíveis em todas as versões Windows SKU.
• Permissões de administrador local.

Ao atualizar para a versão mais recente do Windows 11, você pode precisar de uma reinicialização adicional antes que o recurso Dev Drive fique disponível. Se você estiver trabalhando em um ambiente empresarial empresarial, o administrador de segurança precisará configurar a política de segurança do Dev Drive para habilitar o Dev Drive.

Advertência

O Dev Drive destina-se apenas a cenários chave de desenvolvimento e quaisquer configurações personalizadas ainda serão cobertas por configurações da Diretiva de Grupo em ambientes de trabalho Business ou Enterprise. Saiba mais sobre como configurar a política de segurança do Dev Drive.

Configurar opções

Ser-lhe-ão dadas três opções:

1. Criar novo VHD - Construir volume num novo disco rígido virtual
2. Redimensionar um volume existente - Crie um novo espaço não alocado para construir sobre
3. Espaço não alocado no disco - Use o espaço não alocado em um disco existente. * Essa opção só será exibida se você tiver configurado anteriormente o espaço não alocado em seu armazenamento.

Como escolher entre usar uma partição de disco ou VHD

Há vantagens e compensações a considerar ao escolher se deseja criar uma partição de disco ou criar um novo VHD para armazenar sua unidade de desenvolvimento.

• Criar uma partição de disco: Armazenar sua unidade de desenvolvimento em uma partição de disco geralmente oferecerá um desempenho mais rápido porque usa diretamente o disco físico sem camadas adicionais. As compensações são que o uso de um disco particionado será menos flexível, uma vez que o redimensionamento de partições pode ser mais complexo e arriscado, e menos portabilidade, uma vez que a partição está ligada ao disco físico.

• Criar um novo VHD: Armazenar sua unidade de desenvolvimento em um disco rígido virtual (VHD) pode ter um desempenho ligeiramente menor devido à sobrecarga de gerenciar a camada de disco virtual. As compensações são que os VHDs oferecem mais flexibilidade para redimensionamento dinâmico (se você precisar gerenciar o espaço em disco de forma eficiente), movimentação ou backup de dados. VHDs também são altamente portáteis, permitindo que o arquivo VHD seja transferido para outra máquina ou local de backup. No entanto, tenha em mente que, quando um VHD está hospedado em um disco fixo (HDD ou SSD), não é recomendável copiar o VHD, movê-lo para uma máquina diferente e continuar a usá-lo como uma unidade de desenvolvimento.

Criar novo Disco Rígido Virtual (VHD)

Ao escolher a opção Criar novo VHD para configurar um Dev Drive, terá de determinar o seguinte:

• Nome do disco rígido virtual: dê um nome ao seu VHD (Dev Drive).
• Localização: Atribua um caminho de diretório onde o VHD do Dev Drive estará localizado na sua máquina. O local padrão é C:\. Recomendamos usar um caminho de diretório por utilizador para armazenar o seu Drive de Desenvolvimento, de modo a evitar qualquer partilha não intencional.
• Tamanho do disco rígido virtual: atribua a quantidade de espaço em disco que será alocada para o volume a ser usado, o tamanho mínimo é de 50 GB.
• Formato de disco rígido virtual:
  • VHD: Suporta discos virtuais de até 2040 GB de tamanho.
  • VHDX (Recomendado): Suporta um máximo de 64 TB e oferece uma proteção mais resiliente contra falhas inesperadas de E/S causadas por problemas como falta de energia. Saiba mais sobre como gerenciar VHDs.
• Tipo de disco:
  • Tamanho fixo - Este arquivo de disco rígido virtual é alocado para o tamanho máximo quando criado.
  • Expansão dinâmica - O arquivo de disco rígido virtual cresce até seu tamanho máximo à medida que os dados são gravados no disco. (Recomendado)

Depois de concluir o processo de seleção entre essas opções, o seu Drive de Desenvolvimento será criado.

Redimensionar um volume existente ou usar espaço não alocado em um disco existente

Para redimensionar um volume existente:

1. Escolha um volume para redimensionar.

   

2. Escolha um novo tamanho para o volume. Você precisará ter pelo menos 50 GB de espaço não alocado disponível, o tamanho mínimo necessário para uma unidade de desenvolvimento. Quando o tamanho estiver definido, selecione Avançar.

   

3. Para formatar uma Unidade de Desenvolvimento no novo espaço livre, especifique o Rótulo (nome da unidade), a Letra da Unidade e a Atribuição de Tamanho. O tamanho máximo será a quantidade de espaço livre alocado na etapa anterior, o tamanho mínimo para uma unidade de desenvolvimento é de 50 GB.

   

Parabéns! Agora redimensionaste o teu Dev Drive.

Para localizar e usar espaço não alocado em uma unidade existente, você pode abrir Discos dearmazenamento> do sistema>& volumes, examinar a página para ver se algum espaço de armazenamento está listado como "Não alocado". Selecione Criar volume e terá as opções de Criar volume simples (um volume de armazenamento NTFS padrão) ou Criar unidade de dev. Para criar uma Dev Drive, os passos são os mesmos mencionados acima: necessitará adicionar um Rótulo (nome da unidade), Letra da Unidadee confirmar a alocação do Tamanho.

Formatar um volume de armazenamento como um Dev Drive a partir da linha de comando

Como alternativa ao uso das Configurações do Windows, há duas opções para criar volumes de armazenamento da Unidade de Desenvolvimento a partir da linha de comando. Ambas as opções exigem que você abra a linha de comando como administrador. Tem de ser membro do grupo Administrador para formatar um disco rígido. Esses métodos de formatação de linha de comando podem ser preferidos ao criar várias unidades de desenvolvimento ou como administrador de várias máquinas.

1. Usando a ferramenta de linha de comando Formatar do Windows CMD ou PowerShell:

Format D: /DevDrv /Q

2. Usando o cmdlet Format-Volume do PowerShell:

Format-Volume -DriveLetter D -DevDrive

Esses exemplos de código exigem que substituas D: pelo local da unidade que desejas definir como destino. Consulte os links para obter mais opções e parâmetros de comando.

Como funciona o Dev Drive?

Um Volume de Armazenamento especifica como os dados são armazenados no sistema de arquivos, por meio de diretórios e arquivos, em um formato particular. O Windows usa NTFS para a unidade do sistema e, por padrão, para a maioria das unidades não removíveis. O Resilient File System (ReFS) é um sistema de arquivos da Microsoft mais recente, concebido para maximizar a disponibilidade de dados, dimensionar de forma eficiente para grandes volumes de dados em diversas cargas de trabalho e garantir a integridade dos dados com resistência à corrupção. Ele procura abordar um conjunto crescente de cenários de armazenamento e estabelecer uma base para inovações futuras.

A unidade de desenvolvimento utiliza o ReFS, permitindo que você inicialize um volume de armazenamento especificamente para cargas de trabalho de desenvolvimento, fornecendo desempenho mais rápido e configurações personalizáveis otimizadas para cenários de desenvolvimento. O ReFS contém várias otimizações específicas do sistema de arquivos para melhorar o desempenho dos principais cenários de desenvolvedor.

Saiba mais sobre como o Dev Drive lida com a segurança.

O que devo colocar no meu Dev Drive?

O Dev Drive destina-se a:

• Repositórios de código-fonte e arquivos de projeto
• Caches de pacotes
• Crie arquivos intermediários e de saída

Considerações para instalar ferramentas de desenvolvedor e SDKs no Dev Drive: As ferramentas de desenvolvedor e SDKs geralmente são colocados em um local de administrador ou por usuário. Esses locais fornecem garantias específicas de segurança e isolamento no Windows e afetam o comportamento do Microsoft Defender. No entanto, muitas ferramentas oferecem a flexibilidade de escolher o local de instalação, incluindo uma unidade de desenvolvimento.

Antes de prosseguir com a instalação de ferramentas de desenvolvedor ou SDKs num Dev Drive, avalie os compromissos associados ao sistema e à verificação assíncrona para garantir que estão alinhados com os requisitos de segurança do seu dispositivo e da sua organização. Você tem a opção de criar uma pasta de administrador ou por usuário no Dev Drive. Além disso, é importante verificar se o Modo de Desempenho do Microsoft Defender (por exemplo, verificação assíncrona) atende às suas necessidades de manipulação de binários.

Observação

Os administradores de TI desejarão criar pastas ACL (Lista de Controle de Acesso) por usuário para dispositivos multiusuário como uma prática recomendada para evitar ataques EOP.

Armazenando o cache de pacotes no Dev Drive

Um cache de pacote é o local da pasta global usado pelos aplicativos para armazenar arquivos para o software instalado. Esses arquivos de origem são necessários quando você deseja atualizar, desinstalar ou reparar o software instalado. O Visual Studio é um desses aplicativos que armazena uma grande parte de seus dados no Cache de Pacotes. Depois de alterar as variáveis de ambiente, talvez seja necessário reiniciar todas as janelas abertas do console ou reiniciar o dispositivo para que os novos valores sejam aplicados.

• Cache npm (NodeJS): crie um diretório de cache npm em sua unidade de desenvolvimento, por exemplo D:\packages\npm, e defina uma variável npm_config_cache de ambiente global para esse caminho, por exemplo setx /M npm_config_cache D:\packages\npm. Se você já tiver instalado o NodeJS em sua máquina, mova o conteúdo do %AppData%\npm-cache para este diretório. (Em alguns sistemas, o cache npm pode estar em %LocalAppData%\npm-cache). Saiba mais nos documentos npm: npm-cache e npm config: cache.

• Pasta de pacotes globais do NuGet: a pasta de pacotes globais do NuGet é usada por dotnet, MSBuild e Visual Studio. Crie um diretório NuGet específico do usuário em seu sistema de arquivos CopyOnWrite (CoW). Por exemplo: D:\<username>\.nuget\packages. Use uma das seguintes maneiras de alterar a pasta global-packages do local padrão para a pasta recém-criada (para gerenciar os pacotes instalados globalmente):

  • Defina uma variável NUGET_PACKAGES de ambiente global para esse caminho. Por exemplo: setx /M NUGET_PACKAGES D:\<username>\.nuget\packages.

  • Defina globalPackagesFolder, ao usar PackageReference, ou repositoryPath, ao usar packages.config, para esse caminho nas definições de configuração.

  • Defina a propriedade MSBuild (RestorePackagesPath, apenas MSBuild) para esse caminho.

    Para verificar a pasta global-packages, execute o comando dotnet nuget locals: dotnet nuget locals global-packages --list. A restauração instalará e baixará pacotes no novo caminho. A pasta padrão de pacotes globais do NuGet pode ser excluída. Saiba mais no documentos do NuGet: Gerenciando os pacotes globais, o cache e as pastas temporárias.

Observação

Atualmente, há um problema conhecido: o comando da ferramenta Dotnet não respeita o caminho dos pacotes nuget. A equipa do .NET está ciente e investigando uma correção para o .NET 10 e uma atualização de manutenção para o 8.0 e 9.0.

• cache vcpkg: crie um diretório de cache vcpkg em sua unidade de desenvolvimento, por exemplo D:\packages\vcpkg, e, em seguida, defina uma variável VCPKG_DEFAULT_BINARY_CACHE de ambiente global para esse caminho, por exemplo setx /M VCPKG_DEFAULT_BINARY_CACHE D:\packages\vcpkg. Se você já tiver instalado pacotes, mova o conteúdo de %LOCALAPPDATA%\vcpkg\archives ou %APPDATA%\vcpkg\archives para este diretório. Saiba mais nos documentos vcpkg: vcpkg Binary Caching.

• Pip cache (Python): crie um diretório pip cache no seu Dev Drive, por exemplo D:\packages\pip, e defina uma variável PIP_CACHE_DIR de ambiente global para esse caminho, por exemplo setx /M PIP_CACHE_DIR D:\packages\pip. Se já restauraste pacotes pip e Wheels na tua máquina, move o conteúdo de %LocalAppData%\pip\Cache para este diretório. Saiba mais nos documentos pip: cache pip e veja StackOverflow para Alterar diretório de cache pip no Linux?.

• Cache de carga (Rust): crie um diretório de cache de carga em sua unidade de desenvolvimento, por exemplo D:\packages\cargo, e defina uma variável CARGO_HOME de ambiente global para esse caminho, por exemplo setx /M CARGO_HOME D:\packages\cargo. Se você já restaurou pacotes de carga em sua máquina, mova o conteúdo de %USERPROFILE%\.cargo para este diretório. Saiba mais nos documentos Cargo: Variáveis de Ambiente do Cargo.

• Cache do Maven (Java): crie um diretório de cache do Maven no seu Dev Drive, por exemplo D:\packages\maven, e defina uma variável MAVEN_OPTS de ambiente global para adicionar uma definição de configuração a esse caminho, por exemplo setx /M MAVEN_OPTS "-Dmaven.repo.local=D:\packages\maven". Mova o conteúdo de %USERPROFILE%\.m2\repository para este diretório (isso inclui apenas as dependências, plug-ins e outros artefatos que o Maven baixa para o diretório repository e usa para os seus projetos). Saiba mais na documentação do Maven e consulte o StackOverflow para como especificar um local alternativo para a pasta .m2 ou settings.xml permanentemente?.

• Cache Gradle (Java): Crie um diretório de cache Gradle no seu Dev Drive, por exemplo, D:\packages\gradle. Em seguida, defina uma variável GRADLE_USER_HOME de ambiente global para apontar para esse caminho, por exemplo, use setx /M GRADLE_USER_HOME D:\packages\gradle na linha de comando para defini-lo em todo o sistema. Depois de definir essa variável, o Gradle usará o diretório especificado (D:\packages\gradle) para seus caches e arquivos de configuração. Se você tiver arquivos Gradle existentes, mova o conteúdo de %USERPROFILE%\.gradle para este novo diretório. Para obter informações mais detalhadas, consulte a documentação do Gradle e explore recursos da comunidade, como o StackOverflow, para obter dicas sobre como gerenciar configurações do Gradle e diretórios de cache.

Compreender os riscos de segurança e a confiança em relação ao Dev Drive

Segurança e confiança são considerações importantes ao trabalhar com arquivos de projeto. Normalmente, há uma compensação entre desempenho e segurança. O uso de um Dev Drive coloca o controle sobre este equilíbrio nas mãos dos desenvolvedores e dos administradores de segurança, que têm a responsabilidade de escolher quais filtros serão aplicados e as configurações das análises do Microsoft Defender Antivirus.

Os filtros antivírus, incluindo tanto o Microsoft Defender como os filtros antivírus de terceiros, são anexados a uma Unidade de Desenvolvimento por padrão. O Microsoft Defender Antivírus usa como padrão a nova configuração de "modo de desempenho" em Drives de Desenvolvimento, levando em conta a velocidade e o desempenho, enquanto fornece uma alternativa segura às exclusões de pastas. Para um maior nível de proteção, o Microsoft Defender também oferece o "modo de proteção em tempo real".

Qualquer produto ou recurso que exija filtros adicionais não funcionará, a menos que o filtro seja adicionado ao Dev Drive.

Advertência

As Unidades de Desenvolvimento podem ser executadas sem filtros antivírus anexados. Tenha extrema cautela! A remoção de filtros antivírus é um risco de segurança e significa que a sua unidade de armazenamento não será coberta pelas verificações de segurança padrão. Você é responsável por avaliar os riscos associados à desanexação de filtros antivírus e só deve fazê-lo quando tiver certeza de que seus arquivos armazenados na Unidade de Desenvolvimento não serão expostos a ataques mal-intencionados.

A Microsoft recomenda usar a configuração de desempenho do modo padrão ao utilizar uma Dev Drive confiável .

O que é um Dev Drive "confiável"?

Os Drives de Desenvolvimento são automaticamente designados como confiáveis usando um sinalizador armazenado no registro do sistema durante a formatação original, fornecendo o melhor desempenho possível por padrão. Um Dev Drive confiável significa que o desenvolvedor que utiliza o volume tem grande confiança na segurança do conteúdo aí armazenado.

Semelhante a quando um desenvolvedor escolhe Adicionar uma exclusão àSegurança do Windows, o desenvolvedor assume a responsabilidade de gerir a segurança do conteúdo armazenado para melhorar o desempenho.

Um Dev Drive marcado como confiável é um sinal para que o Microsoft Defender seja executado em modo de desempenho. A execução do Microsoft Defender no modo de desempenho fornece um equilíbrio entre a proteção contra ameaças e o desempenho. A proteção em tempo real ainda estará ativada em todos os outros volumes de armazenamento.

Devido às considerações de segurança de ter filtros desacoplados, o transporte de uma unidade de desenvolvimento entre máquinas resultará no volume sendo tratado como um volume comum sem políticas especiais de aplicação de filtros. O volume precisa ser marcado como confiável quando é associado a uma nova máquina. Consulte Como designar um Dev Drive como confiável?.

Uma Unidade de Desenvolvimento não confiável não terá os mesmos privilégios que uma Unidade de Desenvolvimento confiável . A segurança será executada em modo de proteção em tempo real quando uma Unidade de Desenvolvimento estiver não confiável. Tenha cuidado ao designar confiança para um Dev Drive fora do momento em que é inicialmente criado.

Como designo um Dev Drive como confiável?

Para designar como confiável uma Dev Drive :

1. Abra o PowerShell (ou CMD) com permissões elevadas clicando com o botão direito do mouse e selecionando "Executar como administrador".
2. Para designar sua unidade de desenvolvimento como confiável digite o comando abaixo, substituindo<drive-letter> pela letra da unidade de armazenamento à qual você está designando confiança. Por exemplo, fsutil devdrv trust D:.

fsutil devdrv trust <drive-letter>:

Para confirmar se um Dev Drive é confiável, introduza o comando:

fsutil devdrv query <drive-letter>:

A unidade C: na sua máquina não pode ser designada como um Dev Drive. Ferramentas de desenvolvedor, como Visual Studio, MSBuild, .NET SDK, Windows SDK, etc, devem ser armazenadas em sua unidade C: e não em uma unidade de desenvolvimento.

O que é o modo de desempenho do Microsoft Defender?

O modo de desempenho agora está disponível no Windows 11 como um novo recurso do Microsoft Defender Antivírus. Esse recurso reduz o impacto no desempenho das análises do Microsoft Defender Antivirus em ficheiros armazenados numa Dev Drive designada.

Para saber mais sobre o modo de desempenho e como ele se compara com a proteção em tempo real, consulte Microsoft Defender: Protegendo a unidade de desenvolvimento usando o modo de desempenho.

Para que o modo de desempenho seja ativado, o Dev Drive deve ser designado como confiável e a Proteção em Tempo Real do Microsoft Defender deve ser definida para "Ligado".

Como configuro filtros adicionais no Dev Drive?

Por padrão, o Gerenciador de Filtros desativará todos os filtros em uma Unidade de Desenvolvimento, com exceção dos filtros antivírus. Um filtro antivírus é um filtro que está ligado na FSFilter Anti-Virus faixa de altitude (ou seja, 320000-329999). FSFilter Anti-Virus inclui filtros que detetam e desinfetam vírus durante a E/S de ficheiros.

A política padrão pode ser configurada para não anexar filtros antivírus ao Dev Drive usando fsutil. CUIDADO: Esta política aplica-se a TODOS os drives Dev no sistema.

fsutil devdrv enable /disallowAv

O comando, fsutil devdrv enable [/allowAv|/disallowAv], inclui as duas opções a seguir:

• disallowAv: Especifica que a(s) sua(s) unidade(s) de desenvolvimento não têm filtros associados (nem sequer antivírus). Os filtros podem ser adicionados novamente usando o fsutil devdrv setfiltersallowed <Filter-1> comando. (Substituindo <Filter-1> pelo nome do filtro desejado.)

• allowAv: Especifica que as Dev Drives devem ser protegidas pelo filtro antivírus padrão.

Para obter ajuda, digite o comando: fsutil devdrv enable /?. Se nem /allowAv nem /disallowAv forem especificados, as definições antivírus para a sua Unidade de Desenvolvimento não estão configuradas e o padrão do sistema é proteger as Unidades de Desenvolvimento por um filtro antivírus.

Advertência

Tenha extremo cuidado ao separar filtros. A desanexação de filtros antivírus é um risco de segurança e significa que o seu armazenamento não será coberto pelas verificações padrão do modo de desempenho ou proteção em tempo real do Microsoft Defender. É responsável por avaliar os riscos associados à desanexação de filtros antivírus e só deve fazê-lo quando tiver a certeza de que os seus ficheiros não serão expostos a ataques maliciosos.

Para saber mais sobre filtros, consulte Sobre drivers de filtro do sistema de arquivos, Instalação de um driver de filtro, Conceitos do Gestor de Filtros, Grupos de ordem de carga e altitudes para drivers de minifiltro.

Permitindo que filtros selecionados sejam anexados no Dev Drive

Se estiver a trabalhar num ambiente empresarial ou corporativo, a política de grupo da sua empresa pode estar configurada para selecionar filtros a serem aplicados nos Drives de Desenvolvimento, além da política acima. Um administrador de sistema também pode optar por anexar filtros adicionais a uma Unidade de Desenvolvimento específica ou a todas as Unidades de Desenvolvimento usando uma lista de de permissões.

Um administrador de sistema pode querer adicionar um filtro chamado "Foo", vamos nos referir a ele como FooFlt. Eles podem querer que o filtro esteja apenas ativado no Dev Drive montado como D:. Eles não precisam desse filtro em outro Dev Drive identificado como E:. O administrador pode fazer alterações em uma lista de filtros permitidos no Dev Drive usando ofsutil.exe, um utilitário de linha de comando fornecido pelo sistema.

Filtros definidos especificamente como Permitidos podem ser anexados a uma unidade Dev Drive, além da política de filtro antivírus discutida acima.

Exemplos de filtros de lista de permissões

Os exemplos a seguir demonstram a capacidade de um administrador de definir filtros permitidos em todas as unidades de desenvolvimento em uma máquina, usando uma lista de permissões.

Para usar o comando setfiltersallowed para ativar Filter-01 e Filter-02 em todas as Dev Drives, use o comando:

fsutil devdrv setfiltersallowed Filter-01, Filter-02

Para exibir a política de filtragem associada para todos os Dev Drives, use o comando:

fsutil devdrv query

O resultado exibirá o seguinte:

• Os volumes do desenvolvedor estão habilitados.
• Os volumes de desenvolvedores são protegidos por filtro antivírus.
• Filtros permitidos em qualquer Dev Drive: Filter-01, Filter-02

Para alterar essa configuração da Unidade de Desenvolvimento para permitir apenas Filter-03 na(s) sua(s) Unidade(s) de Desenvolvimento, com Filter-01 e Filter-02 não podem mais ser anexados, use o comando:

fsutil devdrv setfiltersallowed Filter-03

Veja fsutil devdrv /? para outros comandos relacionados.

Filtros para cenários comuns

Os seguintes filtros podem ser usados com o Dev Drive:

Cenário: Descrição	Nome do filtro
GVFS: Alistamentos esparsos do Windows	PrjFlt
MSSense: Microsoft Defender para Endpoint para Sensor EDR	MsSecFlt
Defender: Filtro do Windows Defender	WdFilter
Docker: Executando contêineres fora do Dev Drive	bindFlt, wcifs
Gravador de desempenho do Windows: meça as operações do sistema de arquivos	FileInfo
Monitor de recursos: mostra o uso de recursos. Necessário para mostrar nomes de arquivo na atividade de disco	FileInfo
Process Monitor - Sysinternals: Monitore as atividades do sistema de arquivos	ProcMon24
Atualização do Windows: Usado durante a atualização do sistema operacional. Necessário se o usuário mover a variável de ambiente TEMP para o Dev Drive	WinSetupMon
Windows Defender Application Control (WDAC): Rastreamento gerenciado do instalador com os serviços de identidade do AppLocker	AppLockerFltr

O WdFilter está anexado por padrão. O comando seguinte é um exemplo que demonstra como anexar todos estes filtros adicionais a um Dev Drive.

fsutil devdrv setfiltersallowed "PrjFlt, MsSecFlt, WdFilter, bindFlt, wcifs, FileInfo, ProcMon24"

Sugestão

Para determinar os filtros necessários para um cenário específico, talvez seja necessário marcar temporariamente um Drive de Desenvolvimento como não confiável. Em seguida, execute o cenário e tome nota de todos os filtros aplicados ao volume. Designe novamente a Unidade de Desenvolvimento como confiável e, em seguida, adicione os filtros à lista de Autorização dessa Unidade de Desenvolvimento para garantir o sucesso do cenário. Por fim, remova todos os filtros que possam não ser necessários, um de cada vez, garantindo que o cenário funcione conforme o esperado.

Sugestão

O nome do filtro para Process Monitor pode mudar. Se adicionar o nome do filtro "ProcMon24" não parecer capturar atividades no sistema de ficheiros de um Drive de Desenvolvimento, liste os filtros usando o comando fltmc filters, procure o nome do filtro associado ao Process Monitor e use esse nome em vez de "ProcMon24".

Suporte à clonagem de blocos

A partir do Windows 11 24H2 & Windows Server 2025, a clonagem de blocos agora é suportada no Dev Drive. Como o Dev Drive utiliza o formato de sistema de arquivos ReFS , o suporte à clonagem de blocos significará benefícios de desempenho gratuitos sempre que você copiar um arquivo usando o Dev Drive. A clonagem de blocos permite que o sistema de arquivos copie um intervalo de bytes de arquivo em nome de um aplicativo como uma operação de metadados de baixo custo, em vez de executar operações caras de leitura e gravação nos dados físicos subjacentes. Isso resulta em conclusão de cópia mais rápida, menos E/S para o armazenamento subjacente e maior capacidade de armazenamento, permitindo que vários arquivos compartilhem os mesmos clusters lógicos. Saiba mais sobre a clonagem de blocos.

Quais cenários não são suportados pelo Dev Drive? Quais são as limitações?

Existem alguns cenários em que não recomendamos o uso de uma Dev Drive. Estes são, entre outros:

• Reformatar um volume de armazenamento existente para ser uma "Unidade de desenvolvimento" destruirá qualquer conteúdo armazenado nesse volume. Não há suporte para a reformatação de um volume existente, preservando o conteúdo armazenado lá.
• Quando você cria um VHD (Virtual Hard Disk) hospedado em um disco fixo (HDD ou SSD), não é recomendável copiar o VHD, movê-lo para uma máquina diferente e, em seguida, continuar a usá-lo como uma unidade de desenvolvimento.
• Um volume armazenado num disco removível ou de ligação a quente (como uma unidade externa USB, HDD ou SSD) não suporta a designação como Dev Drive.
• Um volume num VHD hospedado por um disco removível ou encaixável a quente não suporta a designação como um Dev Drive.
• A unidade C: na sua máquina não pode ser designada como um Dev Drive.
• O objetivo de uma unidade de desenvolvimento é hospedar arquivos para criar e depurar projetos de software designados para armazenar repositórios, caches de pacotes, diretórios de trabalho e pastas temporárias. Não recomendamos a instalação de aplicações num Drive de Desenvolvimento.
• Não há suporte para o uso do Dev Drive em discos dinâmicos . Em vez disso, use Espaços de Armazenamento, que ajudarão a proteger seus dados contra falhas de unidade e estender o armazenamento ao longo do tempo à medida que você adiciona unidades ao seu PC.

Como eliminar um Dev Drive

Pode apagar um Dev Drive nas definições do sistema do Windows 11: System>Storage>Disks & volumes.

Abra o menu Configurações do Windows, escolha Armazenamento, Configurações avançadas de armazenamento e, em seguida, Discos & volumes, onde você encontrará uma lista dos volumes de armazenamento no seu dispositivo. Selecione Propriedades ao lado do volume de armazenamento da Unidade de Desenvolvimento que você deseja excluir. Nas propriedades da unidade, encontrará a opção Eliminar sob o título Formatar.

A Dev Drive será apagada. No entanto, se a unidade de desenvolvimento foi criada como um novo VHD, o VHD precisará ser excluído para recuperar o espaço de armazenamento usado por esse VHD. Para fazer isso, você deve desanexar o disco virtual para que o arquivo VHD que hospeda a unidade de desenvolvimento possa ser excluído, seguindo estas etapas:

1. Abra a ferramenta Gerenciamento de disco digitando "Gerenciamento do computador" na caixa de pesquisa na barra de tarefas. Selecione Gerenciamento de disco sob o título Armazenamento. Selecione o disco (não o volume) do Dev Drive. Clique com o botão direito do mouse no disco selecionado que hospeda a unidade de desenvolvimento e, no menu resultante, selecione Desanexar VHD.
2. Será exibida uma janela pop-up informando que a desanexação de um disco rígido virtual o tornará indisponível.
3. Uma vez separado, o VHD pode ser eliminado.

Perguntas frequentes sobre o Dev Drive

Algumas perguntas frequentes sobre o Dev Drive incluem:

Como posso personalizar um Dev Drive para atender às minhas necessidades?

As configurações padrão do Dev Drive foram otimizadas para cenários de desenvolvimento comuns, mas podem ser personalizadas, permitindo o controle sobre drivers e serviços executados no volume de armazenamento. Para personalizar as configurações do Dev Drive, abra o menu Configurações. Em Discos> do sistema >& volumes, vá para Propriedades.

Importante

Se trabalhar para um negócio ou uma empresa, o Dev Drive ainda será gerido pelas definições da sua empresa. Algumas personalizações podem, portanto, não estar disponíveis, dependendo da política da empresa.

Preciso reinstalar meus aplicativos para usar um Dev Drive?

Não, os aplicativos ou ferramentas instalados na unidade C: da sua máquina podem utilizar arquivos de uma unidade de desenvolvimento. Para projetos de desenvolvimento, no entanto, recomendamos armazenar diretórios, arquivos e caches de pacotes específicos do projeto dentro do Dev Drive. A Unidade de Desenvolvimento pode ser fixada no Acesso Rápido do Explorador de Arquivos como lembrete.

O ReFS usa mais memória do que o NTFS?

Sim, o ReFS usa um pouco mais de memória do que o NTFS. Recomendamos uma máquina com pelo menos 8 GB de memória, idealmente 16 GB.

Posso ter mais de um Dev Drive na minha máquina?

Sim. Se tiver espaço, pode criar quantos drives de desenvolvimento desejar. Usar uma unidade de desenvolvimento separada para cada projeto de desenvolvimento de software permitiria que você simplesmente excluísse a unidade no final do desenvolvimento, em vez de reparticionar seu disco novamente. No entanto, lembre-se de que o tamanho mínimo para uma unidade de desenvolvimento é de 50 GB.

O que eu preciso saber sobre como usar o Dev Drive com o Visual Studio?

Depois de criar uma unidade de desenvolvimento, o Visual Studio irá reconhecê-la automaticamente quando você estiver criando um novo projeto ou clonando um projeto existente e escolher esse caminho de arquivo por padrão. Para otimizar o desempenho ao usar o Visual Studio, recomendamos mover qualquer código de projeto, caches de pacotese Copy on write tarefas do MS Build para a Unidade de Desenvolvimento que possam ter sido salvas anteriormente em outro lugar. (Consulte Como alterar o diretório de saída de compilação nos documentos do Visual Studio.) Também recomendamos que você considere redirecionar %TEMP% e %TMP% envvars para o Dev Drive. Isso exigirá também adicionar o WinSetupMon filtro, que é necessário para o processo do Windows Update. (Consulte Filtros para cenários comuns. Muitos programas usam estes, por isso cuidado com potenciais efeitos colaterais. Também recomendamos o uso do modo de desempenho para o Microsoft Defender para ganhos de desempenho assíncronos usando o Dev Drive. Desativar completamente o Microsoft Defender pode resultar no máximo de ganhos de desempenho, mas isso pode aumentar os riscos de segurança e é uma configuração controlada pelo administrador do sistema.

Para obter mais informações, consulte a postagem do blog: Dev Drive para Melhorias de Desempenho no Visual Studio e Dev Boxes.

O Dev Drive funciona com arquivos de projeto WSL?

Você pode acessar os arquivos de projeto do Dev Drive, que são executados no sistema de arquivos do Windows, a partir de uma distribuição Linux em execução via WSL. No entanto, o WSL é executado em um VHD e, para obter o melhor desempenho, os arquivos devem ser armazenados no sistema de arquivos Linux. O WSL está fora do escopo do sistema de arquivos do Windows, portanto, você não deve esperar ver nenhuma melhoria de desempenho ao acessar arquivos de projeto no Dev Drive a partir de uma distribuição Linux em execução via WSL.

Que método é usado para formatar um volume de armazenamento do Windows?

Consulte MSFT_Volume class na documentação de drivers do Windows.

Como configurar e usar o Live Unit Testing com um Dev Drive?

Você pode encontrar orientação sobre como configurar e usar o teste de unidade ao vivo na documentação do Visual Studio. No entanto, esteja ciente de que há uma dependência de ProjFS. Você precisará mover a raiz do espaço de trabalho de Live Unit Testing para o Dev Drive e adicionar o Windows Projected File System à lista de filtros permitidos. Você pode fazer isso usando o seguinte comando no PowerShell:

fsutil devdrv setfiltersallowed PrjFlt

Um VHD criado para uso como uma Unidade de Desenvolvimento será criptografado quando a unidade que o armazena estiver habilitada para BitLocker?

Sim, o VHD da Unidade de Desenvolvimento será incluído na criptografia BitLocker do volume de hospedagem. Não é necessário habilitar o BitLocker no VHD montado.

O Dev Drive pode tornar o desenvolvimento Java mais rápido no Windows?

Sim, usar um Dev Drive pode melhorar a eficiência e reduzir os tempos de construção ao trabalhar em um projeto de desenvolvimento Java. Veja a postagem do blog "Acelere seu desenvolvimento Java no Windows com o Dev Drive".

O Modo de Desempenho do Dev Drive pode ser aplicado a programas antivírus além do Microsoft Defender?

O Modo de Desempenho da Unidade de Desenvolvimento é especificamente um recurso do Microsoft Defender Antivírus relacionado à proteção em tempo real do Defender. Ao usar programas antivírus alternativos com o Dev Drive, o Modo de Desempenho não será aplicado, mas é possível ajustar a Lista de Permissões de filtros de segurança anexados ao Dev Drive para encontrar o equilíbrio certo entre desempenho e segurança para o seu trabalho de desenvolvimento. Você precisará garantir que compreende a função de quaisquer filtros anexados ao fazer alterações na lista de filtros anexada. Encontre uma lista com descrições em Filtros para cenários comuns.

Como posso encontrar um Dev Drive que criei e perdi o controle?

Quando uma unidade de desenvolvimento é montada, mas você esqueceu onde ela está localizada, os seguintes métodos podem ser usados para localizá-la:

• Use o DiskPart e o comando "list vdisk" para mostrar o caminho completo para o vhdx: 1) Abra uma linha de comando e digite diskpart, 2) Quando o DiskPart abrir, digite list vdisk.

• Utilize o PowerShell e "Get-Disk | Select-Object [FriendlyName, Location]": Abra o PowerShell e digite o comando Get-Disk | Select-Object FriendlyName,Location.

Como contribuir para estes documentos e FAQs?

Se você encontrar algum problema nesta documentação ou quiser contribuir com sugestões adicionais de perguntas frequentes, visite o repositório de código aberto do Windows Dev Docs no GitHub.