Dev Drive no Windows 11: como funciona e quando usar Link para o cabeçalho

Disco rígido luminoso com a inscrição Dev Drive flutuando diante de um notebook, enquanto um desenvolvedor observa em pose de adoração.

No post sobre por que OneDrive não é lugar para guardar projeto em desenvolvimento , a ideia central era separar os papéis: OneDrive é ótimo como cofre de documentos, entregáveis e cópias filtradas; ele é péssimo como bancada viva para node_modules, .venv, cache de build, índice de editor e milhares de arquivos mudando ao mesmo tempo.

O Dev Drive entra exatamente nessa conversa.

Ele não é um “D:” com nome bonito. Ele é um tipo de volume do Windows 11 pensado para cargas de desenvolvimento: muitos arquivos pequenos, restauração de pacotes, compilação, clonagem de repositórios, cópias internas, caches e ferramentas que leem e escrevem o tempo todo. A promessa não é milagre. É mais simples: reduzir atrito local onde o Windows normalmente tenta proteger, indexar, filtrar e verificar cada operação de arquivo como se tudo fosse documento de usuário.

Pense assim:

  • Git cuida do histórico.
  • OneDrive cuida de documentos e backups filtrados.
  • O disco local rápido cuida de I/O.
  • O Dev Drive tenta ser o melhor lugar, dentro do Windows, para a parte barulhenta do desenvolvimento.

O que é Dev Drive Link para o cabeçalho

Dev Drive é um volume de armazenamento criado para workloads de desenvolvedor no Windows 11. Ele usa ReFS, o Resilient File System, em vez de NTFS, e recebe políticas específicas de segurança, confiança e filtros de sistema.

Na prática, isso significa que o Windows trata aquele volume como uma área especializada. Não é uma pasta especial dentro do C:. Não é uma configuração de sincronização. Não é só uma exclusão no antivírus. É um volume formatado desde o início como Dev Drive.

Esse detalhe importa: a própria documentação da Microsoft diz que volumes existentes não são convertidos para Dev Drive. A designação acontece no momento de criação/formatação do volume. Se você tem uma pasta C:\Dev hoje em NTFS, ela pode continuar sendo uma boa organização local, mas ela não vira Dev Drive apenas porque você mudou o nome ou aplicou uma configuração.

Por que ele pode ser melhor que um volume local comum Link para o cabeçalho

Um volume NTFS local já é muito melhor do que uma pasta sincronizada em tempo real para desenvolvimento ativo. Se a comparação for “Dev Drive contra OneDrive”, o Dev Drive ganha por categoria: ele não está tentando subir cada cache descartável para a nuvem.

Mas o Dev Drive também tenta melhorar a comparação contra um volume local comum, principalmente por três motivos.

1. ReFS como base Link para o cabeçalho

ReFS é um sistema de arquivos moderno da Microsoft criado para cenários de integridade, escala e resiliência. No Dev Drive, ele aparece como base para otimizações de desenvolvimento.

Uma das funções relevantes é o block cloning. Em vez de copiar fisicamente todos os bytes em alguns cenários compatíveis, o ReFS pode transformar a cópia em uma operação de metadados, fazendo regiões de arquivos compartilharem blocos lógicos no volume. Isso reduz I/O e pode acelerar operações que copiam, duplicam ou reorganizam dados.

Isso não quer dizer que todo comando vai ficar instantâneo. O ganho depende da ferramenta, da versão do Windows, do padrão de arquivos e do tipo de operação. Mas a direção é clara: menos trabalho físico para o disco em operações que o sistema de arquivos consegue representar de forma mais inteligente.

2. Microsoft Defender em modo de desempenho Link para o cabeçalho

Em um volume comum, a proteção em tempo real do antivírus tende a trabalhar de modo síncrono: você abre ou cria um arquivo, o Defender entra no caminho, examina e só então a operação continua.

Em um Dev Drive confiável, o Microsoft Defender pode usar o modo de desempenho. A diferença principal é que a análise passa a ser assíncrona para arquivos daquele volume: abre agora, verifica depois.

Esse ponto é muito melhor do que sair adicionando exclusão ampla para tudo. Uma exclusão comum pode simplesmente tirar uma árvore inteira do radar. O modo de desempenho tenta manter um equilíbrio: reduz impacto no fluxo do desenvolvedor sem desligar a proteção do restante do sistema e sem transformar a pasta em terra sem lei.

Mas há uma condição importante: o modo de desempenho só funciona em Dev Drive confiável, com Microsoft Defender como antimalware principal e proteção em tempo real ligada.

3. Controle de filtros Link para o cabeçalho

O Windows usa filtros de sistema de arquivos para antivírus, backup, criptografia, monitoramento e outras camadas que observam ou interceptam operações. Em workloads normais, isso é parte saudável do sistema. Em desenvolvimento, especialmente com árvores enormes e descartáveis, esses filtros podem virar custo acumulado.

O Dev Drive dá ao administrador mais controle sobre quais filtros podem ser anexados ao volume. É uma área avançada, mas explica por que o recurso não é apenas uma “pasta rápida”: há uma política de volume por baixo.

Como criar um Dev Drive Link para o cabeçalho

O caminho mais amigável é pela interface do Windows:

  1. Abra Configurações.
  2. Vá em Sistema.
  3. Entre em Armazenamento.
  4. Abra Configurações avançadas de armazenamento.
  5. Entre em Discos e volumes.
  6. Escolha Criar unidade de desenvolvimento.

Nos prints oficiais abaixo, a interface aparece em inglês, mas o caminho em pt-BR é o da lista acima. A opção fica dentro de Discos e volumes, ao lado das ações de VHD:

Print oficial do Microsoft Learn mostrando a tela Configurações, Sistema, Armazenamento, Discos e volumes, com o botão Create Dev Drive.

Fonte: Microsoft Learn: Configurar um Dev Drive no Windows 11 .

Na criação, você tem três caminhos principais.

Print oficial do Microsoft Learn mostrando as opções de criação do Dev Drive: criar novo VHD, redimensionar volume existente ou usar espaço não alocado.

Fonte: Microsoft Learn: Configurar um Dev Drive no Windows 11 .

Criar um VHD ou VHDX Link para o cabeçalho

Essa é a opção mais flexível. O Windows cria um disco virtual, anexa esse disco como volume e formata o volume como Dev Drive.

A escolha recomendada pela Microsoft é VHDX, não VHD. O VHDX suporta volumes maiores e é mais resiliente contra falhas inesperadas de I/O, como queda de energia.

Você também escolhe o tipo do disco virtual:

  • Tamanho fixo: ocupa o tamanho total de uma vez.
  • Expansível dinamicamente: cresce conforme os dados são gravados.

Print oficial do Microsoft Learn mostrando o formulário de criação e anexação de VHD para Dev Drive, com VHDX e expansão dinâmica selecionados.

Fonte: Microsoft Learn: Configurar um Dev Drive no Windows 11 .

Para um ambiente pessoal, o VHDX dinâmico costuma ser o caminho menos traumático. Você ganha flexibilidade e pode começar com algo como 80 GB, 120 GB ou 200 GB, dependendo do tamanho dos seus projetos.

O custo é uma camada a mais: um Dev Drive em VHDX pode ser um pouco mais lento do que uma partição física direta, porque existe a camada do disco virtual.

Redimensionar um volume existente Link para o cabeçalho

Se você tem espaço disponível em um disco interno, o Windows pode reduzir um volume existente e criar espaço não alocado. Depois, esse espaço vira um novo Dev Drive.

Esse caminho costuma dar melhor desempenho do que VHDX, porque usa o disco físico diretamente. Em compensação, mexer em partições é mais sensível: exige backup, atenção e menos improviso. Se algo der errado ou se você escolher tamanho ruim, corrigir depois pode ser mais chato.

Usar espaço não alocado Link para o cabeçalho

Se o disco já tem espaço não alocado, o Windows pode criar o Dev Drive ali. É o cenário mais limpo para quem já preparou o particionamento ou tem um segundo SSD interno.

Para máquina de desenvolvimento mais séria, especialmente com monorepo, Android, .NET pesado, Node grande ou builds frequentes, essa é a versão mais bonita da história: um volume dedicado em SSD interno, sem camada virtual e sem OneDrive olhando por cima do ombro.

Requisitos antes de começar Link para o cabeçalho

Antes de criar, confirme os requisitos básicos:

  • Windows 11 build 10.0.22621.2338 ou superior.
  • Permissão de administrador local.
  • Mínimo de 50 GB livres para o Dev Drive.
  • Pelo menos 8 GB de RAM, com 16 GB recomendados.
  • Disco interno. Unidades removíveis ou hot-pluggable não são um bom alvo para Dev Drive.

Em ambientes corporativos, política de grupo, Intune e regras de segurança podem bloquear ou alterar o comportamento. Se o notebook é gerenciado pela empresa, o problema pode não ser técnico no seu usuário, mas política de TI.

O que configurar depois da criação Link para o cabeçalho

Criar o volume é só metade do trabalho. O outro pedaço é colocar as coisas certas lá dentro.

Um layout prático seria:

D:\Dev\
  repos\
  packages\
    npm\
    pip\
    nuget\
    cargo\
    maven\
  temp\

Se o seu Dev Drive for E:, troque D: por E:. A letra em si não é importante. O importante é a fronteira: código ativo e caches barulhentos ficam no Dev Drive; documentos e backups ficam fora.

Confirmar se o volume é Dev Drive Link para o cabeçalho

Abra PowerShell ou CMD como administrador e rode:

fsutil devdrv query D:

Esse comando informa se o volume é Dev Drive, se está confiável e quais filtros estão permitidos ou anexados.

Para consultar todos os Dev Drives do sistema:

fsutil devdrv query

Marcar como confiável Link para o cabeçalho

Dev Drives novos normalmente já são criados como confiáveis. Se você moveu, remontou ou precisa confirmar a política, use:

fsutil devdrv trust D:

E valide:

fsutil devdrv query D:

Confiança aqui não é um selo moral. É uma decisão operacional: você está dizendo ao Windows que aquele volume contém material de desenvolvimento que você controla e que aceita o equilíbrio de segurança/performance do modo de desempenho.

Habilitar o modo de desempenho do Defender Link para o cabeçalho

O Defender precisa estar atualizado, ser o antimalware principal e manter a proteção em tempo real ligada. Para forçar a política via PowerShell administrativo:

Set-MpPreference -PerformanceModeStatus Enabled

Depois, confira no app Segurança do Windows, em Proteção contra vírus e ameaças, se a proteção de Dev Drive aparece habilitada para o volume.

Print oficial do Microsoft Learn mostrando a tela de Segurança do Windows com proteção em tempo real ligada e proteção do Dev Drive ativada.

Fonte: Microsoft Defender for Endpoint: Protect Dev Drive using performance mode .

Mover caches de ferramentas Link para o cabeçalho

Esse é o ajuste que muita gente esquece. Não adianta clonar o repositório no Dev Drive se metade do trabalho pesado continua sendo escrita em %AppData%, %LocalAppData% ou no perfil do usuário.

Para npm:

mkdir D:\Dev\packages\npm
setx /M npm_config_cache D:\Dev\packages\npm

Para pip:

mkdir D:\Dev\packages\pip
setx /M PIP_CACHE_DIR D:\Dev\packages\pip

Para Cargo:

mkdir D:\Dev\packages\cargo
setx /M CARGO_HOME D:\Dev\packages\cargo

Para NuGet:

mkdir D:\Dev\packages\nuget
setx /M NUGET_PACKAGES D:\Dev\packages\nuget

Para Maven:

mkdir D:\Dev\packages\maven
setx /M MAVEN_OPTS "-Dmaven.repo.local=D:\Dev\packages\maven"

Depois de mudar variáveis globais, feche e reabra terminais, IDEs e editores. Em alguns casos, reiniciar o Windows é a forma mais simples de garantir que todo processo herdou as novas variáveis.

O que colocar no Dev Drive Link para o cabeçalho

Coloque coisas que fazem parte do ciclo ativo de desenvolvimento e podem ser reconstruídas:

  • repositórios Git;
  • dependências de projeto;
  • node_modules;
  • .venv;
  • caches de npm, pip, NuGet, Cargo e Maven;
  • diretórios de build;
  • pastas temporárias de ferramentas;
  • workspaces de IDE;
  • clones grandes;
  • árvores geradas que não são fonte canônica.

O critério é simples: se apagar dói pouco porque dá para reconstruir com Git, instalador de pacote ou build, provavelmente é um bom candidato.

O que não colocar no Dev Drive Link para o cabeçalho

Não coloque ali aquilo que deveria ser preservado como documento final ou fonte única:

  • contratos;
  • notas fiscais;
  • planilhas de cliente;
  • PDFs finais;
  • fotos pessoais;
  • backups únicos;
  • arquivos sensíveis sem criptografia ou estratégia;
  • instaladores principais de ferramentas;
  • o único lugar onde um material importante existe.

Também não trate Dev Drive como substituto de Git. O volume pode ajudar sua máquina a trabalhar melhor, mas não registra histórico, não resolve colaboração e não protege contra erro humano.

Dev Drive, OneDrive e backup Link para o cabeçalho

O desenho saudável é:

D:\Dev\                  # Dev Drive, trabalho ativo
  repos\
  packages\
  temp\

OneDrive\
  Documentos\
  Entregaveis\
  DevMirror\             # opcional, espelho filtrado

O Dev Drive é a bancada. O OneDrive é o cofre. Git é o histórico. Backup é outra conversa.

Se você quiser espelhar parte do D:\Dev para OneDrive, use uma estratégia filtrada, como rclone, excluindo dependências, caches, builds, .env, credenciais e diretórios gerados. O pior desenho é sincronização em tempo real tentando acompanhar cada arquivo que o compilador acabou de cuspir.

Dev Drive e WSL Link para o cabeçalho

Você pode acessar arquivos do Dev Drive a partir de uma distribuição WSL quando eles estão no sistema de arquivos do Windows. Mas há uma limitação importante: a opção metadata do WSL, usada para preservar permissões e propriedade Linux em arquivos hospedados no Windows, não é suportada em volumes ReFS.

Então a regra prática fica assim:

  • projeto Windows, tooling Windows, IDE Windows: Dev Drive faz sentido;
  • projeto Linux com permissões Linux importantes: prefira o filesystem interno do WSL;
  • projeto misto simples: dá para acessar o Dev Drive pelo WSL, mas teste antes de transformar em padrão.

Não existe vergonha em usar os dois. O erro é fingir que filesystem não importa.

Comandos úteis de administração Link para o cabeçalho

Consultar:

fsutil devdrv query
fsutil devdrv query D:

Confiar em um volume:

fsutil devdrv trust D:

Remover confiança:

fsutil devdrv untrust D:

Habilitar suporte do sistema:

fsutil devdrv enable

Controlar filtros permitidos:

fsutil devdrv setFiltersAllowed /volume D: nomeDoFiltro

Essa última parte é avançada. Se você não sabe exatamente qual filtro está mexendo e por quê, fique no padrão. A própria Microsoft recomenda usar a configuração padrão do modo de desempenho em um Dev Drive confiável.

Quando vale a pena Link para o cabeçalho

Dev Drive tende a fazer mais sentido quando você tem:

  • projetos com muitos arquivos pequenos;
  • builds frequentes;
  • restauração de pacotes pesada;
  • monorepos;
  • Node, .NET, Java, Rust, Python ou Android com caches volumosos;
  • Defender ativo causando custo perceptível em operações de arquivo;
  • um SSD interno com espaço suficiente.

Ele tende a fazer menos diferença quando:

  • seus projetos são pequenos;
  • você quase não compila localmente;
  • o gargalo real é CPU, memória, rede ou banco remoto;
  • você usa majoritariamente WSL com arquivos dentro do Linux;
  • você esperava que ele substituísse backup.

Performance raramente tem uma causa única. Dev Drive melhora uma parte específica: armazenamento local para workloads de desenvolvimento. Se o problema é falta de RAM, dependência lenta, teste mal paralelizado ou container pesado, ele ajuda pouco.

Receita prática Link para o cabeçalho

Para uma máquina Windows de desenvolvimento, eu faria assim:

  1. Manter ferramentas instaladas no C:, como Visual Studio, SDKs, Windows SDK e apps.
  2. Criar um Dev Drive em D: ou E: com pelo menos 100 GB se houver espaço.
  3. Usar D:\Dev\repos para clones Git.
  4. Usar D:\Dev\packages para caches de npm, pip, NuGet, Cargo e Maven.
  5. Manter OneDrive fora do caminho ativo.
  6. Usar GitHub, GitLab, Azure DevOps ou outro remoto para histórico.
  7. Usar OneDrive ou rclone apenas como espelho filtrado, quando fizer sentido.
  8. Validar com fsutil devdrv query e conferir o modo de desempenho do Defender.

É menos sedutor do que “salva tudo na nuvem e pronto”. Mas é muito mais previsível.

Desenvolvimento moderno já tem complexidade demais. A máquina não precisa inventar mais uma disputa silenciosa entre editor, build, antivírus, sincronizador e cache. Quando cada camada tem um papel claro, o ambiente fica mais rápido, mais diagnosticável e menos irritante.

Checklist rápido Link para o cabeçalho

Antes de chamar seu D: de bancada:

  • O volume é realmente Dev Drive?
  • Ele foi criado como ReFS?
  • O volume aparece como confiável?
  • O Defender está em modo de desempenho para ele?
  • Seus repositórios ativos estão ali?
  • Seus caches de pacote foram movidos?
  • O OneDrive está fora do caminho ativo?
  • Git continua sendo a fonte de histórico?
  • Existe backup ou espelho filtrado para o que importa?

Se essas respostas estiverem boas, o Dev Drive está fazendo o trabalho certo: ser uma área local rápida para a bagunça produtiva do desenvolvimento.

Referências Link para o cabeçalho