# APFS vs ext4 e XFS para agentes: qual é melhor

> Published 2026-10-12T22:56:47.423Z on https://youblog.app/pt/p/apfs-vs-ext4-e-xfs-para-agentes-qual-e-melhor/
> Source video: https://www.youtube.com/watch?v=4wVNFaFDIn8

APFS vs ext4 e XFS para agentes de código é uma comparação que decide quanto tempo você perde esperando clonar repositórios e rodar pnpm install. Em benchmarks reproduzidos em vídeo, um Mac com APFS levou cerca de 39 segundos na tarefa de instalar e limpar node_modules, enquanto a mesma tarefa ficou perto de 11,5 segundos em ext4.

## APFS vs ext4 e XFS: o que os benchmarks mostram

APFS vs ext4 e XFS para agentes de código é uma disputa de tempo em operações de arquivos pequenos, não de velocidade bruta do SSD. Nos testes apresentados por Theo, criador de conteúdo e desenvolvedor da comunidade t3.gg, o Mac com APFS levou cerca de 39 segundos na tarefa de instalar e limpar node_modules, contra aproximadamente 2,5 segundos de limpeza no ext4.

O benchmark citado é o [disk-bench](https://github.com/novocas/disk-bench) mantido por novocas, que clona vários boilerplates de frameworks web e mede quanto tempo cada sistema leva para instalar os módulos npm e depois apagá-los. Os números que importam são a razão entre as duas máquinas, não o valor absoluto de uma única rodada.

| Sistema | Limpeza | Instalação |
| --- | --- | --- |
| APFS (M1 Max) | ~39 s | ~40 s |
| ext4 | ~2,5 s | ~9 s |
| XFS | ~7 s | ~9,5 s |
| XFS + VDO | ligeiramente acima do XFS | ~10 s |
| ZFS | lento em hard links | >5 s na limpeza |

Os dados acima vêm de medições feitas pelo próprio autor do vídeo em máquinas dele, não de um estudo independente. Trate como experiência de primeira mão, reproduzível apenas se você montar uma configuração semelhante.

## O que a APFS otimiza e por que isso atrapalha devs

A APFS foi projetada para durabilidade, criptografia por arquivo e snapshots em iPhones e Macs, não para exclusão massiva e cópia de milhares de arquivos minúsculos. A [documentação da Apple](https://developer.apple.com/documentation/foundation/file_system) descreve a APFS como sistema padrão desde o macOS High Sierra, em 2017, com foco em confiabilidade e segurança.

O custo aparece quando o agente precisa clonar um repositório e rodar pnpm install. A cópia em lote de arquivos pequenos gera uma sobrecarga de metadados que domina o tempo total, e o drive rápido não compensa isso.

O mesmo padrão aparece em work trees paralelos. Criar oito work trees ao mesmo tempo no macOS quase não melhora em relação a criar um por vez, enquanto ext4 e XFS mantêm o custo agregado próximo do linear.

## ext4, XFS, ZFS e Btrfs: qual escolher para agentes

Entre as opções Linux, o ext4 ganha em simplicidade e velocidade de escrita de arquivos pequenos, mas não tem copy-on-write nem compressão nativa. O [XFS](https://docs.kernel.org/filesystems/xfs/xfs-delayed-logging-design.html) é mais extensível e aceita camadas de compressão por cima, o que muda a conta de espaço em disco.

O ZFS e o [Btrfs](https://btrfs.readthedocs.io/en/latest/) foram feitos pensando em RAID e integridade de dados com checksums. Nesse cenário de agentes, eles custam caro: no teste relatado, o ZFS demorou quase 8 segundos para criar um work tree contra menos de 1 segundo do ext4.

Não existe resposta única. O ZFS continua sendo escolha sólida para NAS e armazenamento doméstico, função que o próprio autor do vídeo mantém. O critério aqui é apenas o fluxo de trabalho com muitos repositórios clonados em paralelo.

## XFS com VDO e LZ4: compressão sem penalidade pesada

XFS com VDO e compressão LZ4 permite guardar vários pedaços de dados no mesmo bloco, reduzindo espaço sem exigir muito processamento. O [VDO](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/deduplicating_and_compressing_storage/) é a camada de deduplicação e compressão da Red Hat, e o [LZ4](https://github.com/lz4/lz4) é um compressor leve conhecido justamente por leituras e escritas rápidas.

A hipótese do vídeo era que o custo de CPU da compressão anularia o ganho de espaço. O resultado medido foi o contrário: o desempenho se manteve próximo do XFS puro na maioria dos testes de agentes.

Esse é o ponto de informação mais útil para quem decide: em 125 work trees com pnpm install rodado, o ext4 puro ocupou 75 GB, o APFS ocupou 43 GB e a configuração XFS com VDO ocupou cerca de 24 GB. A redução de espaço vem da combinação de deduplicação, compressão e links, não de um único recurso.

## Hard links e cópia de arquivos em repositórios grandes

Hard links fazem vários caminhos apontarem para os mesmos dados no disco, e é por isso que eles reduzem drasticamente o consumo de espaço em node_modules. ([IBM](https://www.ibm.com/docs/en/aix/7.3?topic=files-hard-links) mantém uma explicação técnica sobre o conceito.)

O ganho depende do sistema. Com hard links, o XFS ficou próximo do ext4 no benchmark de limpeza e instalação, caindo de cerca de 7 segundos para 2,85 segundos em um dos cenários. Na APFS, a criação de links saiu de aproximadamente 40 segundos para cerca de 100 segundos no teste, o que mostra que o recurso existe, mas com custo alto.

A limitação é de projeto, não de configuração. Um agente que cria work trees constantemente vai bater nesse custo várias vezes por dia.

## Quando vale usar soluções de virtualização de arquivos

Ferramentas de virtualização de arquivos criam uma visão temporária dos arquivos para o agente trabalhar, sem persistir cópias até que haja escrita real. No Mac, isso pode tornar a criação de work trees quase instantânea, o que resolve o problema sem trocar de sistema operacional.

O exemplo citado é o Rift, uma ferramenta com CLI publicada no [npm](https://www.npmjs.com/package/rift-cli). Segundo o relato do vídeo, ela é focada em macOS e o repositório não recebia commits havia cerca de dois meses na época da gravação, o que indica risco de projeto parado.

Vale considerar esse tipo de ferramenta como paliativo. Ela não substitui um sistema de arquivos adequado para o volume de arquivos pequenos que um fluxo com agentes gera, especialmente quando você precisa de consistência real em disco.

## Como montar sua própria configuração em 2026

Montar uma máquina Linux para agentes é mais barato do que comprar um Mac novo e resolve o gargalo de forma direta, desde que você aceite manter dois ambientes. Em 2026, o próprio autor do vídeo relata que a maior parte do código que ele trabalha roda em um computador Linux na rede doméstica.

O roteiro que o vídeo descreve passa por particionar um disco separado do disco do sistema, formatar com XFS e ativar a camada VDO com compressão. Vale medir o seu próprio caso antes de migrar tudo, porque o ganho depende do número de work trees e do tamanho médio dos arquivos.

1. Instale uma distribuição Linux em uma máquina separada.
2. Use um disco dedicado, diferente do disco do sistema operacional.
3. Formate com XFS e ative VDO com compressão LZ4.
4. Configure pnpm para usar hard links.
5. Meça limpeza, instalação e criação de work trees antes e depois.

Quem já estuda esse tipo de fluxo pode se interessar pelo [Crazystack Typescript](https://crazystack.com.br), uma formação voltada para a stack TypeScript no Brasil, e por conteúdos do Gustavo Dev Doido sobre montagem de ambiente de desenvolvimento. Ambos aparecem no ecossistema brasileiro de desenvolvedores que acompanham esse tipo de otimização.

## Perguntas frequentes sobre APFS, ext4 e XFS

- **APFS é ruim para desenvolvimento com agentes?** A APFS prioriza durabilidade e segurança, e essas escolhas custam tempo em exclusões massivas e cópia de arquivos pequenos. Nos benchmarks relatados, ela ficou entre 3 e 5 vezes mais lenta que o ext4 na limpeza de node_modules.

- **Vale a pena trocar o sistema de arquivos do Mac?** O macOS não suporta bem outros sistemas de arquivos, e o vídeo relata que a tentativa de particionar o SSD para outro formato não deu certo. Para aproveitar XFS com VDO, o caminho prático é usar uma máquina Linux separada.

- **O que é copy-on-write em sistemas de arquivos?** Copy-on-write significa que uma cópia aponta para os mesmos dados originais até que um dos lados seja alterado, momento em que o bloco é duplicado. Isso economiza espaço em work trees e clones de repositório, mas a implementação varia muito entre ZFS, Btrfs e XFS.

- **Compressão no sistema de arquivos deixa o computador lento?** Depende do compressor. O LZ4 é leve o bastante para que o custo de CPU não domine o tempo de leitura e escrita, e nos testes relatados o XFS com VDO ficou próximo do XFS puro em desempenho.

- **Qual sistema de arquivos usar para muitos node_modules?** Para repositórios grandes com centenas de dependências, ext4 e XFS com hard links se saíram melhor nos testes relatados. APFS e ZFS tiveram custo alto na criação de links, e Btrfs sofreu com cópia em lote de arquivos pequenos.

- **Preciso de hardware novo para melhorar isso?** Não necessariamente. O gargalo medido estava no sistema de arquivos, não na velocidade do SSD, e o vídeo relata que uma máquina Linux comum superou um M1 Max nas tarefas de limpeza e instalação.

- **O Ganho de espaço em disco é real?** Nos dados relatados, uma configuração XFS com VDO ocupou cerca de 24 GB em um cenário com 125 work trees, contra 75 GB do ext4 puro. É uma diferença relevante para quem trabalha com muitos repositórios ao mesmo tempo.

- **Existe solução pronta para Mac sem trocar de sistema?** O Rift é uma tentativa nessa direção, com virtualização de arquivos e copy-on-write voltados ao macOS. O projeto parecia parado na época do vídeo, então trate como experimental.

- **Como medir o ganho no meu próprio projeto?** Clone o repositório do disk-bench e rode as tarefas de limpeza e instalação nos seus discos. Compare também o espaço ocupado após criar dezenas de work trees, porque é aí que a diferença se acumula.

## Feche o ciclo do seu conhecimento técnico

Se você chegou até aqui discutindo sistemas de arquivos, benchmarks de limpeza e o custo real de rodar agentes em paralelo, provavelmente também tem experiência acumulada que merece virar texto. Muita coisa boa fica presa em vídeos longos, sem uma versão escrita que outras pessoas possam encontrar depois.

O [Skala Blog](https://skalablog.com) faz exatamente essa ponte: você cola a URL de um vídeo do YouTube, o conteúdo é transcrito e vira um artigo estruturado, pronto para revisão. É uma forma prática de aproveitar o que você já explicou em vídeo e transformar em material escrito.

[Source video](https://www.youtube.com/watch?v=4wVNFaFDIn8)