Você abre as propriedades de uma pasta no Windows 11 e encontra duas informações aparentemente contraditórias:
Tamanho: 8,20 GB
Tamanho em disco: 9,47 GB
Em outro arquivo acontece justamente o contrário:
Tamanho: 20 GB
Tamanho em disco: 6 GB
Como um arquivo pode ocupar mais espaço no SSD do que seu próprio tamanho?
E, mais estranho ainda:
como um arquivo pode ter 20 GB e ocupar somente 6 GB no disco?
Não se trata necessariamente de erro do Windows, defeito no SSD ou cálculo incorreto do Explorador de Arquivos.
Para entender esses números precisamos separar conceitos que normalmente aparecem misturados:
- tamanho lógico do arquivo;
- espaço alocado;
- clusters;
- tamanho da unidade de alocação;
- NTFS;
- arquivos pequenos;
- compressão;
- Sparse Files;
- metadados do sistema de arquivos.
Essa diferença também explica situações como:
- uma pasta com milhares de arquivos pequenos ocupar muito mais espaço do que o esperado;
- um arquivo de poucos bytes consumir alguns kilobytes;
- duas unidades contendo os mesmos arquivos apresentarem “Tamanho em disco” diferente;
- um arquivo enorme ocupar fisicamente muito menos espaço;
- copiar uma pasta para outro disco alterar o espaço utilizado;
- compactação NTFS reduzir “Tamanho em disco” sem alterar o “Tamanho” original.
Antes de tentar liberar espaço, precisamos entender o que cada número representa.
Primeiro: o que significa “Tamanho”?
Vamos imaginar um arquivo chamado:
relatorio.txt
Seu conteúdo possui exatamente:
1.000 bytes
De maneira simplificada, o campo:
Tamanho
representa o tamanho lógico dos dados do arquivo.
Se o arquivo contém 1.000 bytes de dados, seu tamanho lógico é aproximadamente isso.
Mas o armazenamento não precisa reservar espaço em incrementos de exatamente um byte para cada arquivo.
É aqui que entram as unidades de alocação.
O SSD trabalha diretamente com arquivos do Windows?
Não da maneira que o usuário enxerga.
Para nós existem:
foto.jpg
documento.docx
video.mp4
programa.exe
Para o sistema de arquivos existe toda uma estrutura responsável por representar:
- arquivos;
- diretórios;
- atributos;
- localização dos dados;
- permissões;
- datas;
- nomes;
- metadados.
Em uma instalação típica do Windows 11, a partição principal normalmente utiliza:
NTFS.
O que é NTFS?
NTFS significa:
New Technology File System
É o sistema de arquivos tradicionalmente utilizado pelo Windows em volumes do sistema.
Ele fornece recursos muito além de simplesmente “guardar arquivos”.
Entre eles estão mecanismos relacionados a:
- permissões;
- journaling;
- links;
- atributos;
- compressão;
- arquivos esparsos;
- grandes volumes;
- metadados.
Para este artigo, porém, uma característica nos interessa imediatamente:
a forma como o espaço é alocado para os arquivos.
O que é um cluster?
Um cluster é uma unidade de alocação utilizada pelo sistema de arquivos para organizar espaço destinado aos dados.
Também encontramos o termo:
Allocation Unit
ou:
unidade de alocação.
Vamos imaginar, para fins didáticos, um volume cujo tamanho de cluster seja:
4 KB
Isso significa que a alocação dos dados de um arquivo normalmente ocorre em unidades desse tamanho.
Arquivo de 1 byte pode ocupar 4 KB?
Em uma explicação simplificada sobre alocação por clusters, sim: um arquivo que precisa de espaço alocado pode acabar consumindo uma unidade inteira de alocação, mesmo que seu conteúdo seja muito menor.
Isso parece desperdício.
Mas faz parte da maneira como sistemas de arquivos administram armazenamento.
Exemplo simplificado
Considere clusters de:
4 KB
Agora temos um arquivo de:
1 KB
Ele não precisa de quatro clusters.
Um cluster já comporta os dados.
Então podemos ter conceitualmente:
Tamanho: 1 KB
Espaço alocado: 4 KB
Sobram aproximadamente:
3 KB
naquela unidade de alocação.
Esse espaço restante pode ser entregue para outro arquivo comum?
Em uma explicação simplificada do armazenamento convencional de dados por clusters:
não simplesmente como se o segundo arquivo pudesse ocupar o restante livre daquele mesmo cluster já alocado ao primeiro arquivo.
Essa diferença contribui para o chamado:
slack space.
Agora um arquivo de 4 KB
Com cluster de 4 KB:
Arquivo: 4 KB
Alocação: aproximadamente 4 KB
O aproveitamento é muito melhor.
E um arquivo de 5 KB?
Agora um cluster não é suficiente.
Precisamos de mais espaço alocado.
Conceitualmente:
Arquivo: 5 KB
Alocação: 8 KB
Temos dois clusters de 4 KB.
Portanto, o crescimento ocorre em degraus
Em nosso exemplo:
Arquivo de 1 KB → 4 KB alocados
Arquivo de 4 KB → 4 KB alocados
Arquivo de 5 KB → 8 KB alocados
Arquivo de 8 KB → 8 KB alocados
Arquivo de 9 KB → 12 KB alocados
Essa é uma excelente maneira de entender por que:
Tamanho e Tamanho em disco podem ser diferentes.
Mas existe uma ressalva importante no NTFS
A realidade interna do NTFS é mais sofisticada do que a regra:
“todo arquivo pequeno ocupa obrigatoriamente um cluster inteiro.”
Alguns arquivos muito pequenos podem ter seus dados armazenados dentro do próprio registro da MFT.
Isso é chamado de:
dado residente.
Portanto, não devemos transformar o exemplo dos clusters em uma regra absoluta para qualquer arquivo existente no NTFS.
O que é MFT?
MFT significa:
Master File Table.
Ela é uma estrutura fundamental do NTFS.
Arquivos e diretórios possuem registros associados na MFT contendo informações importantes.
Dependendo do tamanho e dos atributos, dados muito pequenos podem permanecer residentes no próprio registro.
Esse detalhe explica por que ferramentas diferentes podem apresentar resultados que não correspondem perfeitamente à matemática simplificada de:
tamanho ÷ cluster
Então por que ensinar o exemplo de 4 KB?
Porque ele explica muito bem o conceito básico de alocação.
Mas um diagnóstico técnico precisa saber que existem exceções e recursos adicionais do NTFS.
Como descobrir o tamanho do cluster?
No Windows podemos utilizar:
fsutil fsinfo ntfsinfo C:
O resultado apresenta várias informações técnicas sobre o volume NTFS.
Entre elas podemos encontrar dados relacionados a:
Bytes Per Cluster
Outro comando útil
Também podemos consultar informações do volume com ferramentas do próprio Windows.
Mas evite alterar parâmetros do sistema de arquivos apenas para experimentar.
Aqui nosso objetivo é:
consultar.
4 KB é sempre o tamanho do cluster?
Não.
O tamanho da unidade de alocação pode variar conforme:
- sistema de arquivos;
- formatação;
- tamanho do volume;
- configuração escolhida.
Por isso, dois volumes podem armazenar a mesma coleção de arquivos e utilizar quantidades diferentes de espaço alocado.
Esse detalhe é extremamente importante
Imagine dois discos.
Disco A
Cluster:
4 KB
Disco B
Cluster:
64 KB
Agora copiamos milhares de arquivos minúsculos para ambos.
A diferença de espaço alocado pode se tornar significativa.
Exemplo extremo
Imagine:
100.000 arquivos de 1 KB
O tamanho lógico total seria aproximadamente:
100 MB
Agora considere, de maneira simplificada, uma alocação mínima de 4 KB por arquivo.
Teríamos algo próximo de:
400 MB de espaço alocado
antes de considerar outros detalhes.
Agora com unidades de alocação de 64 KB
Na mesma simplificação:
100.000 × 64 KB
produziria um valor enorme em comparação aos 100 MB de conteúdo lógico.
Esse exemplo mostra por que o tamanho da unidade de alocação pode importar muito quando existem quantidades gigantescas de arquivos pequenos.
Isso significa que cluster menor é sempre melhor?
Não.
Esse seria outro erro.
O tamanho da unidade de alocação envolve compromissos.
Não existe um valor universalmente perfeito para todos os cenários.
Para o usuário comum, devo formatar tudo manualmente com cluster diferente?
Normalmente não existe motivo para alterar a configuração padrão apenas porque você descobriu o conceito de cluster.
Os padrões do sistema de arquivos existem justamente para atender bem aos cenários comuns.
Não formate um disco para “corrigir Tamanho em disco”
Se existe uma diferença grande, primeiro descubra:
- quantidade de arquivos;
- tamanho médio;
- sistema de arquivos;
- unidade de alocação;
- compressão;
- arquivos esparsos.
Formatar sem diagnóstico pode destruir dados e não resolver a causa.
Pastas com milhares de arquivos pequenos
Esse é um dos cenários em que a diferença fica muito visível.
Imagine uma pasta contendo:
- caches;
- pequenos arquivos de configuração;
- miniaturas;
- arquivos temporários;
- logs pequenos.
O tamanho lógico somado pode ser relativamente baixo.
Mas cada arquivo precisa ser representado e armazenado pelo sistema de arquivos.
Por isso duas pastas de 1 GB podem se comportar de forma diferente
Pasta A
Contém:
um arquivo de 1 GB
Pasta B
Contém:
500.000 arquivos pequenos totalizando 1 GB
Ambas possuem aproximadamente:
1 GB de tamanho lógico.
Mas isso não significa que ocuparão exatamente o mesmo espaço em disco ou terão o mesmo desempenho durante cópia.
Quantidade de arquivos importa
Essa informação será muito importante também para outro assunto:
por que copiar milhares de arquivos pequenos é muito mais lento do que copiar um arquivo grande.
Mas aqui nosso foco é o espaço.
O Windows precisa armazenar mais do que o conteúdo?
Sim.
Um sistema de arquivos também administra metadados.
O arquivo não é apenas seus bytes de conteúdo.
Existem informações relacionadas a:
- nome;
- atributos;
- datas;
- permissões;
- referências internas;
- localização dos dados.
Então “Tamanho” não representa todo o custo estrutural daquele arquivo
Correto.
O valor exibido como tamanho é principalmente uma informação sobre o conteúdo lógico do arquivo.
O sistema de arquivos precisa fazer muito mais para gerenciá-lo.
“Tamanho em disco” é o consumo real do SSD?
É uma aproximação muito mais ligada ao espaço alocado para aquele arquivo, mas a expressão precisa ser interpretada com cuidado.
Não devemos pensar nela como uma medição física perfeita de cada célula NAND ocupada dentro de um SSD.
NTFS e SSD são camadas diferentes
Isso é fundamental.
O NTFS trabalha com sua visão lógica do volume.
O SSD possui internamente:
- controladora;
- NAND;
- páginas;
- blocos;
- Flash Translation Layer;
- garbage collection;
- over-provisioning.
Portanto:
cluster NTFS ≠ página física da NAND.
Não tente mapear diretamente 4 KB do NTFS para “4 KB físicos do SSD”
São camadas diferentes.
O sistema operacional enxerga armazenamento lógico.
A controladora do SSD administra a mídia física internamente.
Então o que o Explorer está mostrando?
Ele está apresentando informações derivadas da visão do sistema de arquivos.
Isso é o que interessa para:
- capacidade do volume;
- arquivos;
- espaço livre;
- alocação.
Agora chegamos a uma situação ainda mais interessante
Até aqui explicamos principalmente por que:
Tamanho em disco pode ser MAIOR que Tamanho.
Mas no início deste artigo também mostramos o contrário:
Tamanho: 20 GB
Tamanho em disco: 6 GB
Como isso é possível?
Existem alguns mecanismos capazes de produzir esse tipo de resultado.
Um deles é:
compressão.
Outro é:
Sparse File.
Compressão NTFS
O NTFS possui suporte a compressão de arquivos.
Quando um arquivo pode ser comprimido eficientemente, seu tamanho lógico continua representando os dados que o programa enxerga depois da descompressão transparente.
Mas a quantidade de espaço alocado pode ser menor.
Exemplo conceitual
Arquivo lógico:
1 GB
Depois da compressão NTFS, espaço necessário:
400 MB
O usuário continua trabalhando com um arquivo cujo conteúdo lógico possui aproximadamente 1 GB.
Mas o sistema de arquivos pode precisar de menos espaço para armazená-lo.
Isso funciona bem com qualquer arquivo?
Não.
Alguns formatos já são fortemente comprimidos.
Exemplos comuns:
- JPEG;
- MP4;
- ZIP;
- 7z.
Tentar comprimi-los novamente pode gerar pouco benefício.
Arquivos altamente compressíveis
Textos, determinados logs e outros dados repetitivos podem apresentar redução muito maior.
Compressão não é a única explicação
Existe um mecanismo ainda mais curioso:
Sparse Files.
O que é um Sparse File?
Um arquivo esparso permite representar grandes regiões que não precisam possuir armazenamento físico alocado da maneira convencional.
Isso é especialmente útil quando existem grandes áreas logicamente vazias.
Imagine um arquivo lógico de 100 GB
Mas apenas:
5 GB
contêm regiões efetivamente alocadas com dados relevantes.
Dependendo da estrutura do arquivo, podemos ter:
Tamanho: próximo de 100 GB
Tamanho em disco: muito menor.
Isso parece impossível apenas se pensarmos em arquivo como uma caixa
O modelo mental tradicional é:
arquivo de 100 GB = 100 GB obrigatoriamente ocupados.
Sparse Files quebram essa associação.
O tamanho lógico e a quantidade de espaço alocado podem ser muito diferentes.
Onde isso pode aparecer?
Arquivos esparsos podem ser utilizados em cenários como:
- virtualização;
- imagens de disco;
- bancos de dados;
- aplicações especializadas;
- arquivos que reservam grandes regiões lógicas.
VHD e VHDX ajudam a visualizar o conceito
Um disco virtual pode representar uma capacidade lógica grande sem necessariamente consumir toda essa capacidade no armazenamento físico desde o primeiro momento.
Os detalhes dependem do formato e configuração, mas o princípio ajuda a entender por que:
capacidade lógica
e:
espaço efetivamente utilizado
não precisam ser iguais.
Não confunda Sparse File com compressão
São mecanismos diferentes.
Compressão
Armazena uma representação comprimida dos dados.
Sparse
Permite que determinadas regiões logicamente existentes não precisem receber alocação convencional quando representam áreas sem dados significativos.
E um arquivo pode envolver mais de um recurso?
O NTFS possui diversos atributos e mecanismos, portanto precisamos analisar o arquivo real em vez de assumir uma única explicação.
Como saber se o problema é quantidade de arquivos?
Comece pelas propriedades da pasta.
Observe:
- tamanho;
- tamanho em disco;
- número de arquivos;
- número de pastas.
Se existem centenas de milhares ou milhões de arquivos pequenos, isso é uma pista importante.
Como saber se existe compressão NTFS?
No Explorer, propriedades avançadas do arquivo ou pasta podem indicar a opção de compressão de conteúdo para economizar espaço.
Também existem ferramentas de linha de comando para consultar compressão.
Comando compact
O Windows possui:
compact
Ele pode consultar e administrar compressão NTFS em cenários apropriados.
Para começar, use-o como ferramenta de consulta e leia o resultado antes de modificar qualquer coisa.
E Sparse Files?
Ferramentas do Windows também conseguem consultar determinados atributos e informações de arquivos.
Mas antes de entrar nos comandos avançados precisamos entender exatamente o que estamos procurando.
Não tente “desesparsificar” arquivos aleatoriamente
Se um programa criou um Sparse File, provavelmente existe uma razão.
Alterar a estrutura sem compreender o software pode aumentar drasticamente o consumo de espaço ou causar problemas.
Por que esse assunto é importante em suporte técnico?
Porque o usuário pode olhar:
Tamanho: 200 GB
e concluir:
“Preciso de 200 GB livres para copiar isso.”
Dependendo do tipo de arquivo e do destino, a história pode ser mais complicada.
Copiar para outro sistema de arquivos pode mudar o resultado
Esse é um ponto fundamental.
Ao copiar um arquivo para outro volume, características do destino podem ser diferentes:
- sistema de arquivos;
- cluster;
- suporte a recursos;
- compressão;
- comportamento em relação a sparse files.
Por isso:
copiar o mesmo conteúdo não garante o mesmo “Tamanho em disco”.
Backup também precisa entender essas características
Uma ferramenta de backup precisa saber lidar corretamente com características especiais do sistema de arquivos.
Caso contrário, um arquivo que ocupava pouco espaço na origem pode consumir muito mais no destino.
E ZIP?
Compactar arquivos em ZIP é diferente de usar compressão NTFS.
No ZIP:
os arquivos são armazenados dentro de um contêiner compactado.
Na compressão NTFS:
o sistema de arquivos trata a compressão de maneira transparente para os aplicativos.
E “Compactar esta unidade para economizar espaço”?
Essa opção merece uma análise cuidadosa.
Não deve ser ativada indiscriminadamente apenas porque o disco está cheio.
Antes, descubra:
- quais dados ocupam espaço;
- quais arquivos são compressíveis;
- impacto de CPU;
- tipo de armazenamento;
- função da máquina.
Falta de espaço deve ser diagnosticada
Não comece pela compressão.
Primeiro identifique:
quem está ocupando o armazenamento.
TreeSize e ferramentas semelhantes
Ferramentas de análise de espaço ajudam a visualizar:
- pastas grandes;
- quantidade de arquivos;
- distribuição de dados.
Mas os números também precisam ser interpretados considerando:
- hard links;
- sparse files;
- compressão;
- permissões;
- arquivos inacessíveis.
Explorer e ferramenta de terceiros podem mostrar números diferentes?
Sim.
Ferramentas podem utilizar métodos e definições diferentes para calcular:
- tamanho lógico;
- tamanho alocado;
- hard links;
- arquivos especiais.
Uma pequena diferença não significa automaticamente que uma delas está errada.
A pergunta correta é: o que exatamente está sendo medido?
Essa pergunta vale para praticamente todas as ferramentas de armazenamento.
Por que milhares de arquivos pequenos podem desperdiçar tanto espaço?
Na Parte 1 estabelecemos uma diferença fundamental:
Tamanho e Tamanho em disco não representam exatamente a mesma coisa.
Agora podemos analisar um dos casos em que essa diferença se torna muito evidente:
pastas contendo milhares ou milhões de arquivos pequenos.
Esse cenário aparece com frequência em:
- caches;
- perfis de navegadores;
- programas de desenvolvimento;
- bancos de pequenos arquivos;
- pastas temporárias;
- logs;
- miniaturas;
- bibliotecas de aplicativos;
- arquivos de configuração;
- estruturas criadas por determinados programas.
Uma pasta pode apresentar:
Tamanho: 2,8 GB
e:
Tamanho em disco: 4,1 GB
Em casos extremos, a diferença pode ser ainda maior.
Para entender por quê, precisamos aprofundar o conceito de unidade de alocação.
Cluster é uma unidade de gerenciamento do sistema de arquivos
Vamos novamente utilizar um exemplo didático.
Imagine um volume formatado com clusters de:
4 KB
Temos um arquivo cujo conteúdo possui:
3 KB
Na simplificação convencional de alocação, ele utiliza uma unidade de 4 KB.
Então temos aproximadamente:
3 KB de conteúdo
dentro de:
4 KB alocados
A diferença é aproximadamente:
1 KB.
Um único arquivo não parece importante
Perder aproximadamente 1 KB é irrelevante para um SSD moderno.
Mas agora multiplique isso por:
500.000 arquivos.
A situação muda.
O desperdício se acumula
Esse espaço que fica sem aproveitamento no final da unidade de alocação pode contribuir para o chamado:
slack space.
Não estamos falando necessariamente de espaço “perdido para sempre”.
Estamos falando de espaço dentro de unidades já alocadas que não está sendo utilizado pelo conteúdo lógico daquele arquivo da maneira convencional.
Exemplo didático com 100 mil arquivos
Imagine:
100.000 arquivos
Cada um com:
1 KB
Tamanho lógico aproximado:
100.000 KB
ou aproximadamente:
100 MB, usando uma simplificação decimal para facilitar o exemplo.
Agora considere clusters de 4 KB.
Se cada arquivo precisar de uma unidade inteira:
100.000 × 4 KB = 400.000 KB
O espaço alocado pode ficar muito acima do tamanho lógico.
Agora mude o cluster para 64 KB
Na mesma simplificação:
100.000 × 64 KB
A diferença torna-se enorme.
Isso mostra por que o tamanho da unidade de alocação é particularmente importante para conjuntos com muitos arquivos pequenos.
Mas lembre-se da exceção do NTFS
Como explicamos na Parte 1, arquivos muito pequenos podem ter dados residentes na MFT.
Portanto, não pegue a fórmula:
número de arquivos × tamanho do cluster
e espere que ela represente perfeitamente qualquer pasta NTFS real.
Ela é excelente para entender o conceito.
Não é um modelo completo de todos os detalhes internos do NTFS.
Por que arquivos grandes sofrem menos com esse efeito?
Imagine um arquivo de:
10 GB
e cluster de:
4 KB
Mesmo que exista alguma sobra na última unidade de alocação, ela representa uma fração minúscula do tamanho total.
Arquivos pequenos são o cenário mais crítico
Considere:
arquivo de 1 KB
versus:
arquivo de 10 GB.
A sobra potencial de alguns kilobytes tem peso enorme proporcionalmente no primeiro.
No segundo, praticamente desaparece em relação ao total.
É por isso que quantidade de arquivos importa
Duas pastas podem possuir:
10 GB de tamanho lógico
e ainda apresentar comportamento muito diferente.
Pasta A
10 arquivos de aproximadamente 1 GB.
Pasta B
2 milhões de arquivos pequenos totalizando 10 GB.
A Pasta B possui muito mais trabalho estrutural para o sistema de arquivos.
E não é apenas espaço
Milhares de arquivos pequenos também influenciam:
- enumeração de diretórios;
- criação de arquivos;
- abertura;
- fechamento;
- metadados;
- antivírus;
- cópia;
- backup.
Esse é o motivo pelo qual uma pasta com milhões de pequenos arquivos pode ser muito mais lenta para copiar do que um único arquivo gigantesco.
Mas isso será assunto para outro post
Aqui continuaremos concentrados no consumo de armazenamento.
O que significa “unidade de alocação”?
Ao formatar determinados volumes no Windows, podemos encontrar uma opção chamada:
Tamanho da unidade de alocação
Ela corresponde ao tamanho de cluster utilizado pelo sistema de arquivos.
Por que o Windows oferece “Tamanho de alocação padrão”?
Porque a escolha depende de características como:
- sistema de arquivos;
- tamanho do volume;
- uso esperado.
Para o usuário comum, o padrão normalmente é a opção mais sensata.
Não escolha 64 KB só porque parece maior e mais rápido
Esse é um erro.
Unidades maiores podem ter vantagens em determinados cenários específicos, mas também podem desperdiçar muito mais espaço quando existem grandes quantidades de arquivos pequenos.
Também não escolha o menor valor apenas para economizar espaço
Tamanho de cluster envolve outros fatores.
Não existe:
“menor cluster = sempre melhor.”
Como descobrir o tamanho do cluster de um volume NTFS?
Podemos usar:
fsutil fsinfo ntfsinfo C:
Procure pela informação equivalente a:
Bytes Per Cluster
Em um sistema configurado em português, alguns textos podem aparecer traduzidos dependendo da ferramenta e versão.
Exemplo conceitual
Se o resultado mostrar:
Bytes Per Cluster : 4096
temos:
4096 bytes por cluster
ou:
4 KiB.
KB ou KiB?
Aqui existe outra pequena confusão.
Tecnicamente:
1 KiB = 1024 bytes
enquanto o prefixo decimal:
1 kB = 1000 bytes.
No uso cotidiano, Windows, fabricantes e usuários nem sempre apresentam essas unidades de maneira que deixe a diferença evidente.
Isso também aparece na capacidade dos SSDs
Um SSD vendido como:
1 TB
não aparece necessariamente no Windows como exatamente:
1.000 “GB” da forma que o usuário imagina.
Existe uma diferença entre convenções decimais e binárias, além de partições e outros fatores.
Mas isso é outro assunto.
Como consultar clusters em outro volume?
Se o volume for:
D:
podemos adaptar o comando:
fsutil fsinfo ntfsinfo D:
desde que estejamos lidando com NTFS e tenhamos as permissões necessárias.
E se for exFAT?
O comando específico de informações NTFS obviamente não serve para analisar internamente exFAT como se ele fosse NTFS.
Isso nos leva a outra questão:
o sistema de arquivos também importa.
NTFS, FAT32 e exFAT não são iguais
O Windows pode trabalhar com diferentes sistemas de arquivos.
Entre os mais conhecidos:
- NTFS;
- FAT32;
- exFAT.
Cada um possui características e finalidades diferentes.
NTFS
É o sistema normalmente utilizado na unidade do Windows.
Oferece recursos como:
- ACLs e permissões;
- journaling;
- compressão;
- hard links;
- reparse points;
- sparse files;
- vários atributos avançados.
FAT32
É muito conhecido por compatibilidade ampla com diferentes dispositivos.
Mas possui limitações importantes.
Uma das mais famosas é o limite de tamanho para arquivos individuais em torno de:
4 GB.
Portanto, tentar copiar um arquivo muito grande para FAT32 pode falhar mesmo existindo bastante espaço livre.
“Tenho 100 GB livres, mas não copia um arquivo de 8 GB”
Se o destino usa FAT32, a quantidade de espaço livre pode não ser o problema.
O limite do sistema de arquivos pode ser.
exFAT
exFAT é muito utilizado em:
- unidades removíveis;
- cartões;
- pendrives;
- armazenamento externo.
Ele elimina algumas limitações práticas do FAT32 e possui boa interoperabilidade em vários cenários.
Mas exFAT não é simplesmente “NTFS moderno para pendrive”
São sistemas de arquivos diferentes.
Eles possuem estruturas e recursos diferentes.
Por que o mesmo conjunto de arquivos pode ocupar mais no pendrive?
Um dos motivos possíveis é:
tamanho de cluster diferente.
Exemplo
Pasta no SSD NTFS:
Tamanho: 500 MB
Tamanho em disco: 530 MB
Depois da cópia para uma unidade com uma unidade de alocação muito maior:
Tamanho: continua próximo de 500 MB
Tamanho em disco: pode crescer consideravelmente.
O conteúdo não ficou maior
O arquivo não ganhou dados magicamente.
Mudou a maneira como o sistema de arquivos de destino aloca o espaço.
Essa diferença aparece muito com pequenos arquivos
Fotos grandes e vídeos tendem a sofrer proporcionalmente menos com slack space.
Pastas com:
- milhares de XML;
- JSON;
- pequenos TXT;
- pequenos scripts;
- caches;
podem mostrar diferença muito maior.
“Copiei 20 GB e o pendrive perdeu 30 GB”
Antes de suspeitar de defeito, verifique:
- quantidade de arquivos;
- tamanho médio;
- sistema de arquivos;
- unidade de alocação;
- arquivos especiais.
Formatar com outro cluster resolveria?
Pode alterar a utilização do espaço.
Mas formatar destrói o conteúdo do volume se não houver backup adequado.
Além disso, você precisa considerar:
- compatibilidade;
- finalidade;
- desempenho;
- tamanho dos arquivos;
- sistema de arquivos.
Não faça isso apenas para reduzir um número exibido pelo Explorer.
Cluster grande pode ser adequado em algum cenário?
Sim.
Ambientes que trabalham predominantemente com arquivos grandes podem possuir requisitos diferentes de uma unidade cheia de milhões de arquivos minúsculos.
O importante é não transformar isso em recomendação universal.
Agora vamos entender melhor o slack space
Imagine cluster de 4 KiB.
Arquivo:
6 KiB
Ele precisa de dois clusters na nossa simplificação:
8 KiB alocados.
Sobram:
2 KiB
na última unidade.
O desperdício máximo depende do tamanho do cluster
Quanto maior a unidade de alocação, maior pode ser a sobra no último cluster de cada arquivo.
Em média, para uma distribuição variada de tamanhos, podemos ter uma quantidade relevante de espaço não utilizado ao final das alocações.
Milhões de arquivos amplificam o efeito
É por isso que sistemas contendo enormes árvores de arquivos pequenos merecem atenção especial.
Um arquivo de zero bytes ocupa espaço?
Essa pergunta é interessante.
Um arquivo vazio possui:
0 bytes de conteúdo lógico.
Mas ele ainda precisa existir como uma entrada no sistema de arquivos e possui metadados.
No NTFS, sua representação envolve a MFT e outras estruturas.
Portanto, “arquivo vazio” não significa literalmente que sua existência não tenha nenhum custo estrutural para o sistema de arquivos.
E uma pasta vazia?
Também precisa ser representada.
O sistema de arquivos precisa manter informações sobre aquele diretório.
Então 1 milhão de arquivos vazios não é igual a nada
Exatamente.
Mesmo sem conteúdo convencional, existe enorme quantidade de objetos e metadados para administrar.
Isso também afeta backup
Uma ferramenta de backup pode processar:
1 arquivo de 100 GB
muito mais facilmente do que:
10 milhões de arquivos totalizando 100 GB.
Não por causa apenas dos bytes, mas pela quantidade de operações necessárias.
Antivírus também precisa analisar arquivos
Quando você copia milhares de arquivos, software de segurança pode examinar cada item.
Isso não altera necessariamente a definição de tamanho lógico, mas influencia enormemente o tempo necessário para a operação.
Por que ZIP pode ajudar nesse cenário?
Se você compacta milhares de arquivos pequenos em um único arquivo ZIP, passa a ter:
um arquivo maior
em vez de:
milhares de pequenos arquivos individuais no destino.
Isso pode reduzir o efeito de slack relacionado aos arquivos individuais dentro do sistema de arquivos externo ao ZIP.
Além disso, pode existir compressão
Se os arquivos forem compressíveis, o ZIP também reduz o conteúdo armazenado.
Mas ZIP muda a forma de acesso
Você não possui mais milhares de arquivos independentes diretamente no volume.
Eles estão dentro de um contêiner.
Portanto, isso não é uma solução universal.
Exemplo prático
Imagine uma pasta de projeto com:
300.000 pequenos arquivos
Tamanho lógico:
2 GB
Tamanho em disco:
3,5 GB
Depois de criar um ZIP:
1 arquivo
Tamanho:
1,2 GB
Tamanho em disco:
próximo do tamanho do próprio arquivo, dependendo da alocação.
Temos dois efeitos:
- compressão;
- redução da quantidade de arquivos externos.
Não use esse exemplo como garantia de proporção
O resultado depende do conteúdo.
Arquivos já comprimidos podem praticamente não diminuir.
JPEG, MP4 e ZIP
Esses formatos normalmente já utilizam técnicas de compressão.
Colocar milhares de JPEGs dentro de ZIP pode trazer benefício limitado de compressão.
Mas ainda transforma muitos arquivos em um único contêiner.
“Tamanho em disco” maior significa fragmentação?
Não necessariamente.
Essa é outra confusão comum.
Diferença entre:
Tamanho
e:
Tamanho em disco
não é uma medida direta de fragmentação.
Fragmentação é outro conceito
Um arquivo pode ter seus dados distribuídos em diferentes regiões lógicas do volume.
Isso não é a mesma coisa que slack space.
SSD elimina a questão de clusters?
Não.
SSD muda a tecnologia física de armazenamento.
Mas o volume ainda possui sistema de arquivos e unidades de alocação.
NTFS continua existindo sobre SSD
Portanto, conceitos como:
- MFT;
- clusters;
- atributos;
- arquivos;
- diretórios;
continuam relevantes.
“Meu NVMe usa páginas, então cluster não importa”
As páginas internas da NAND pertencem a outra camada.
O NTFS continua trabalhando com sua organização lógica.
Por que precisamos separar camadas?
Porque misturar:
cluster NTFS
com:
página NAND
leva a conclusões erradas sobre armazenamento.
Camada simplificada
Podemos pensar assim:
Aplicativo
↓
Windows
↓
NTFS / sistema de arquivos
↓
armazenamento lógico
↓
controladora do SSD
↓
NAND
Cada camada possui sua própria lógica.
Tamanho em disco pertence principalmente à visão do sistema de arquivos
Não é uma leitura direta das células físicas ocupadas dentro do SSD.
E over-provisioning?
SSDs podem possuir capacidade interna reservada para gerenciamento.
Isso não aparece simplesmente como “Tamanho em disco” de cada arquivo.
É outro nível da arquitetura.
E garbage collection?
Também pertence ao gerenciamento interno do SSD.
Não confunda com espaço alocado pelo NTFS.
E TRIM?
TRIM permite que o sistema informe ao SSD sobre blocos lógicos que não precisam mais manter dados válidos em determinados contextos.
Novamente:
isso não muda a definição básica do campo “Tamanho” exibido pelo Explorer.
Uma pasta pode mostrar números diferentes enquanto está sendo calculada?
Sim.
Quando você abre propriedades de uma pasta enorme, o Explorer precisa enumerar os arquivos.
Você pode observar os valores aumentando durante o cálculo.
Milhões de arquivos podem levar muito tempo
Isso não significa necessariamente SSD lento.
Enumerar enorme quantidade de objetos exige trabalho.
Explorer pode não conseguir acessar tudo
Permissões também podem influenciar análises de determinadas pastas.
Uma ferramenta executada com outro contexto de privilégio pode enxergar arquivos diferentes.
Por isso ferramentas podem discordar
Antes de concluir que uma ferramenta está errada, pergunte:
- analisaram exatamente os mesmos arquivos?
- possuíam as mesmas permissões?
- tratam hard links da mesma forma?
- consideram sparse files?
- mostram tamanho lógico ou alocado?
Hard links complicam ainda mais a conta
No NTFS, múltiplos nomes podem referenciar os mesmos dados por meio de hard links.
Isso pode confundir ferramentas que simplesmente somam tamanhos de caminhos encontrados.
Exemplo conceitual
Se dois nomes representam hard links para o mesmo conteúdo, somar ambos ingenuamente pode fazer parecer que existe o dobro de armazenamento físico alocado para os dados.
Não necessariamente existe.
Isso é particularmente importante no Windows
Algumas estruturas do sistema utilizam mecanismos que podem fazer ferramentas simples superestimarem o consumo.
Por isso não apague pastas do Windows com base apenas no “tamanho aparente”
Esse aviso é fundamental.
Uma pasta parece gigantesca.
Usuário conclui:
“Achei 30 GB para apagar.”
Mas a medição pode envolver:
- hard links;
- arquivos especiais;
- componentes compartilhados.
WinSxS é um exemplo famoso
A pasta de componentes do Windows exige interpretação adequada.
Não deve ser apagada manualmente para liberar espaço.
“Tamanho em disco” também pode ser MENOR
Na próxima etapa do artigo, essa será nossa principal investigação.
Até agora aprofundamos:
por que Tamanho em disco pode ficar maior.
Agora precisamos explicar detalhadamente o cenário inverso.
Quando Tamanho em disco fica menor que Tamanho?
Entre as principais hipóteses estão:
- compressão NTFS;
- Sparse Files;
- características específicas do arquivo e do sistema de arquivos.
E aqui começam os casos realmente surpreendentes
Você pode encontrar:
Tamanho: 50 GB
Tamanho em disco: 8 GB
E isso pode estar perfeitamente correto.
Como um arquivo de 100 GB pode ocupar apenas 10 GB no SSD?
Nas partes anteriores analisamos principalmente o cenário em que:
Tamanho em disco > Tamanho
Isso acontece com frequência quando existem muitos arquivos pequenos e o sistema de arquivos precisa trabalhar com unidades de alocação.
Agora vamos inverter a situação.
Imagine abrir as propriedades de um arquivo e encontrar:
Tamanho: 100 GB
Tamanho em disco: 12 GB
A primeira reação pode ser:
“O Windows está calculando errado.”
Não necessariamente.
Existem mecanismos capazes de separar de maneira muito significativa:
tamanho lógico e espaço alocado.
Entre os mais importantes estão:
- compressão NTFS;
- Sparse Files;
- arquivos dinamicamente expansíveis;
- hard links, quando analisamos conjuntos de arquivos e pastas.
Vamos entender cada um.
Tamanho lógico não é uma promessa de ocupação física equivalente
Esse é provavelmente o conceito mais importante de todo o artigo.
Quando um aplicativo pergunta ao sistema qual é o tamanho de determinado arquivo, pode receber uma resposta referente ao:
comprimento lógico do arquivo.
Isso não significa necessariamente que o sistema de arquivos tenha reservado exatamente a mesma quantidade de armazenamento para representá-lo.
Pense em duas perguntas diferentes
Pergunta 1
Até onde vai o arquivo?
Pergunta 2
Quanto armazenamento precisou ser alocado para guardar seu conteúdo?
Parecem a mesma pergunta.
Não são.
Compressão NTFS
O NTFS suporta compressão transparente.
Isso significa que um programa pode trabalhar com o conteúdo normalmente enquanto o sistema de arquivos cuida da compressão e descompressão.
Para o aplicativo, o arquivo continua possuindo seu tamanho lógico.
No armazenamento, entretanto, pode consumir menos espaço.
Exemplo simples
Imagine um arquivo de texto contendo grandes quantidades de dados repetitivos.
Tamanho lógico:
10 GB
Depois da compressão NTFS, suponha que os dados necessitem de:
2 GB
de espaço alocado.
Podemos então encontrar uma diferença considerável entre:
Tamanho
e:
Tamanho em disco.
O arquivo virou ZIP?
Não.
Essa distinção é importante.
Quando você cria:
arquivo.zip
você cria um contêiner compactado.
Para acessar normalmente os arquivos internos, aplicações trabalham com o formato ZIP ou extraem seu conteúdo.
Na compressão NTFS, o processo ocorre de maneira transparente no sistema de arquivos.
O programa pode nem saber que o arquivo está comprimido
Em muitos cenários, o aplicativo simplesmente:
- abre;
- lê;
- grava;
- fecha.
O NTFS cuida dos detalhes de compressão.
Como verificar compressão NTFS?
O Windows possui o comando:
compact
Executado em um Prompt de Comando, ele pode fornecer informações sobre compressão de arquivos e diretórios.
Consultar antes de alterar
Essa regra vale para praticamente todas as ferramentas deste artigo.
Primeiro:
observe.
Depois:
interprete.
Somente então decida se existe motivo para modificar algo.
Não ative compressão apenas porque o SSD está cheio
Compressão pode ajudar em determinados cenários.
Mas falta de espaço deve começar por diagnóstico.
Descubra:
- quais pastas estão grandes;
- quais arquivos cresceram;
- se existem temporários;
- backups antigos;
- máquinas virtuais;
- imagens de disco;
- caches;
- dados duplicados;
- arquivos pessoais grandes.
Nem todo arquivo comprime bem
Imagine:
video.mp4
Muitos vídeos já utilizam codecs que comprimem fortemente os dados.
Compressão adicional pode produzir ganho pequeno.
O mesmo vale frequentemente para:
- JPEG;
- PNG em determinados conteúdos;
- ZIP;
- RAR;
- 7z;
- arquivos de mídia comprimidos.
Outros conteúdos podem comprimir muito
Por exemplo:
- TXT;
- determinados CSV;
- logs;
- XML;
- código-fonte;
- alguns bancos de dados;
- dados altamente repetitivos.
O resultado depende do conteúdo real.
Compressão possui custo
Para acessar dados comprimidos, existe trabalho computacional envolvido.
Em computadores modernos, esse custo pode ser aceitável em muitos cenários, mas não deve ser ignorado.
Então compressão é boa ou ruim?
Nenhuma das duas respostas serve universalmente.
Depende do caso.
A pergunta correta é:
qual problema estamos tentando resolver e qual tipo de dado estamos armazenando?
Agora chegamos aos Sparse Files
Esse mecanismo costuma surpreender ainda mais.
Sparse File significa:
arquivo esparso.
O que é um arquivo esparso?
Imagine um arquivo cujo comprimento lógico seja:
100 GB.
Mas grande parte desse espaço lógico representa regiões contendo zeros ou áreas que não precisam receber armazenamento convencional naquele momento.
Em vez de reservar imediatamente 100 GB, o sistema de arquivos pode representar determinadas regiões como não alocadas.
Resultado conceitual
Podemos ter:
Tamanho lógico: 100 GB
mas:
Espaço alocado: 8 GB
O restante desapareceu?
Não.
O espaço existe na estrutura lógica do arquivo.
Mas não precisa corresponder a clusters fisicamente alocados para todas aquelas regiões.
O que acontece quando o programa lê uma região não alocada?
O sistema consegue tratar essas regiões de acordo com a semântica do arquivo esparso, normalmente apresentando zeros ao leitor sem precisar armazenar fisicamente uma gigantesca sequência de zeros.
Isso é muito eficiente
Imagine armazenar:
90 GB de zeros.
Uma abordagem convencional poderia literalmente gravar bilhões de bytes representando zeros.
Um mecanismo esparso pode representar que aquela região não possui dados alocados.
Uma analogia
Imagine um caderno com 1.000 páginas numeradas.
Somente 50 possuem texto.
Em vez de fabricar fisicamente todas as 1.000 páginas em branco, você mantém uma estrutura dizendo:
- páginas 1–100: vazias;
- página 101: possui dados;
- páginas 102–500: vazias;
- página 501: possui dados.
A analogia não representa exatamente a implementação do NTFS, mas ajuda a visualizar a ideia.
O arquivo pode ser enorme sem consumir a mesma capacidade
Essa é a característica principal.
Onde Sparse Files são úteis?
Podem aparecer em:
- virtualização;
- imagens de disco;
- bancos de dados;
- aplicações científicas;
- sistemas de armazenamento;
- programas que trabalham com grandes espaços lógicos;
- arquivos que crescem de maneira não contínua.
Como o Windows sabe que um arquivo é sparse?
NTFS possui atributos e estruturas para representar esse comportamento.
O Windows oferece ferramentas capazes de consultar e manipular determinados aspectos.
Uma delas é:
fsutil sparse
Consultando o estado de um arquivo
Dependendo da versão e sintaxe disponível no Windows, fsutil sparse permite trabalhar com informações relacionadas a Sparse Files.
Como fsutil possui funções administrativas e pode modificar características do sistema de arquivos, não execute comandos de alteração aleatoriamente em arquivos importantes.
Não transforme um arquivo comum em Sparse File “para economizar espaço”
Marcar um arquivo com determinado atributo não significa magicamente comprimir seus dados existentes.
Sparse Files fazem sentido quando o padrão de dados e a aplicação utilizam corretamente esse mecanismo.
Sparse não é compressão
Vamos reforçar a diferença.
Compressão
O sistema tenta representar os dados utilizando menos espaço.
Exemplo conceitual:
AAAAAAAAAAAAAAAA
pode ser representado de maneira mais eficiente por um algoritmo de compressão.
Sparse
Grandes regiões que não precisam possuir alocação podem permanecer sem clusters convencionais associados.
Os dois conceitos resolvem problemas diferentes
Um arquivo pode possuir muitos dados altamente compressíveis sem ser sparse.
Outro pode possuir enormes regiões vazias e ser um excelente candidato à representação esparsa.
VHD e VHDX ajudam a entender
Máquinas virtuais são um bom exemplo conceitual de separação entre:
capacidade virtual
e:
espaço consumido no armazenamento hospedeiro.
Imagine criar um disco virtual com capacidade máxima de:
200 GB.
Isso não significa necessariamente que um arquivo de 200 GB precise aparecer imediatamente no SSD do computador hospedeiro.
Disco virtual dinamicamente expansível
Dependendo da configuração, um disco virtual pode começar pequeno e crescer conforme dados são adicionados.
Então podemos ter:
capacidade virtual máxima: 200 GB
mas:
arquivo atualmente consumindo 25 GB.
Isso não é exatamente a mesma coisa que Sparse File
É importante não misturar os conceitos.
Um formato de disco virtual dinamicamente expansível possui sua própria estrutura.
O exemplo serve para demonstrar um princípio:
capacidade lógica não precisa ser igual ao armazenamento atualmente utilizado.
Um VHDX pode crescer
À medida que a máquina virtual grava mais dados, o arquivo hospedeiro pode aumentar.
Mas apagar arquivos dentro da máquina virtual reduz imediatamente o VHDX?
Não necessariamente.
Essa é outra confusão comum.
Imagine:
- VHDX cresce para 100 GB;
- você apaga 50 GB dentro da máquina virtual;
- espera que o arquivo hospedeiro caia automaticamente para 50 GB.
Isso pode não acontecer.
Espaço livre interno e tamanho externo são coisas diferentes
A máquina virtual pode considerar determinadas regiões livres.
Mas o contêiner externo pode continuar mantendo espaço previamente alocado.
Compactação ou otimização específica pode ser necessária dependendo do cenário.
Esse conceito aparece em muitos sistemas
A diferença entre:
espaço lógico livre
e:
espaço fisicamente/alocadamente devolvido
não existe apenas em VHDX.
É uma ideia recorrente em armazenamento.
Agora vamos falar de hard links
Hard links introduzem outro tipo de confusão.
Eles não são simplesmente uma forma de compressão.
Também não são Sparse Files.
O que é um hard link?
No NTFS, mais de um nome pode referenciar o mesmo conteúdo de arquivo.
De maneira simplificada:
arquivoA.dll
e:
arquivoB.dll
podem representar nomes diferentes associados aos mesmos dados.
Isso significa duas cópias completas?
Não necessariamente.
Esse é justamente o ponto.
Imagine um arquivo de 1 GB
Existem dois hard links apontando para o mesmo conteúdo.
Uma ferramenta ingênua pode percorrer os dois caminhos e somar:
1 GB + 1 GB = 2 GB
Mas isso não significa que existam necessariamente 2 GB de dados independentes alocados.
Isso pode causar enormes confusões em analisadores de espaço
Especialmente quando analisamos estruturas complexas do Windows.
WinSxS é um exemplo clássico de interpretação incorreta
Usuários podem olhar o tamanho aparente de determinadas estruturas e concluir:
“O Windows duplicou tudo.”
Mas hard links e outros mecanismos podem fazer uma soma simples por caminhos superestimar o consumo real.
Não apague WinSxS manualmente
A pasta:
C:\Windows\WinSxS
faz parte do Component Store do Windows.
Apagar arquivos manualmente dali pode comprometer:
- atualizações;
- recursos;
- reparos;
- componentes do sistema.
“Mas minha ferramenta diz que ela tem 20 GB”
O número precisa ser interpretado de acordo com a forma como a ferramenta trata hard links e outros elementos.
Como identificar hard links?
O Windows possui ferramentas capazes de consultar links associados a arquivos.
Por exemplo, fsutil possui recursos relacionados a hard links.
Um comando de consulta pode ajudar a descobrir os nomes associados ao mesmo arquivo.
PowerShell também pode ajudar em determinadas análises
Mas o ponto principal não é decorar comandos.
É entender que:
dois caminhos não significam obrigatoriamente duas cópias físicas independentes dos dados.
Isso muda completamente a análise de espaço
Imagine um programa que soma todos os tamanhos encontrados durante a enumeração de diretórios.
Se não detectar hard links adequadamente, pode contar os mesmos dados mais de uma vez.
Então qual ferramenta está certa?
Depende do que cada uma está medindo.
Uma pode responder:
“Qual é a soma lógica dos arquivos encontrados?”
Outra:
“Quanto espaço alocado exclusivo esses dados representam?”
Essas perguntas podem gerar respostas diferentes.
Esse é o motivo pelo qual analisadores de armazenamento discordam
Não devemos comparar apenas o número final.
Precisamos saber a metodologia.
O Explorador também não é um analisador forense de armazenamento
As propriedades do Explorer são excelentes para uso cotidiano.
Mas estruturas avançadas do sistema de arquivos exigem ferramentas e interpretação apropriadas.
Outra diferença: arquivos comprimidos dentro de pastas
Imagine uma pasta com:
Tamanho: 30 GB
mas muitos arquivos utilizam compressão NTFS.
O espaço alocado total pode ser:
18 GB.
Isso pode ser perfeitamente normal.
Como identificar arquivos comprimidos visualmente?
O Explorer possui opções de exibição que podem apresentar arquivos NTFS comprimidos de forma diferenciada, dependendo das configurações.
Mas não dependa exclusivamente de cor ou aparência.
Ferramentas como compact fornecem informações mais objetivas.
O atributo “Compactar conteúdo para economizar espaço”
Nas propriedades avançadas de arquivos ou pastas NTFS podemos encontrar uma opção semelhante a:
Compactar o conteúdo para economizar espaço em disco.
Quando aplicada a uma pasta, a configuração pode envolver os arquivos existentes e novos itens conforme a escolha realizada.
Cuidado em diretórios do sistema
Não saia comprimindo:
C:\Windows
inteiro apenas para tentar ganhar alguns gigabytes.
Existem mecanismos e ferramentas apropriadas para manutenção do Windows.
Windows também possui CompactOS
Em determinados cenários, o Windows possui um mecanismo chamado:
CompactOS
Ele permite manter determinados arquivos do sistema operacional comprimidos.
Como consultar?
Existe o comando:
compact.exe /CompactOS:query
Ele consulta o estado relacionado ao CompactOS.
Isso é diferente de compactar um ZIP
Novamente, estamos falando de mecanismos integrados ao sistema operacional e ao armazenamento dos arquivos.
Devo ativar CompactOS manualmente?
Não apenas porque existe o comando.
Primeiro determine:
- espaço disponível;
- tipo de equipamento;
- configuração atual;
- necessidade real.
O próprio Windows pode administrar esse recurso em determinados dispositivos e cenários.
Espaço livre também pode parecer “sumir”
Nem toda diferença de capacidade livre está relacionada aos arquivos que você encontra no Explorer.
O volume também pode conter estruturas e dados relacionados a:
- sistema de arquivos;
- MFT;
- restauração;
- snapshots;
- paginação;
- hibernação;
- componentes do Windows;
- metadados.
Por isso somar todas as pastas nem sempre reproduz perfeitamente o espaço usado
Essa é outra pergunta frequente:
“Meu SSD mostra 300 GB usados, mas somando minhas pastas encontro só 250 GB.”
Existem vários possíveis motivos.
Permissões podem esconder parte da conta
Um programa executado sem privilégios suficientes pode não conseguir enumerar determinados diretórios.
Arquivos de sistema também contam
Por exemplo:
pagefile.sys
hiberfil.sys
podem representar quantidades relevantes de armazenamento dependendo da configuração.
Pontos de restauração e Shadow Copies
Também podem consumir armazenamento que o usuário não percebe simplesmente navegando pelas pastas pessoais.
Não tente resolver isso apagando arquivos protegidos
A investigação deve identificar corretamente o responsável.
“Tamanho em disco menor” significa que o SSD está economizando NAND?
Na perspectiva do volume, significa que o sistema de arquivos precisou alocar menos espaço lógico para representar aquele arquivo.
Mas devemos continuar evitando uma equivalência direta com células NAND físicas.
A controladora do SSD mantém sua própria camada
Ela administra aspectos como:
- tradução de endereços;
- garbage collection;
- wear leveling;
- blocos físicos;
- páginas;
- reserva interna.
O Explorer não apresenta esse mapa físico.
Portanto, existem pelo menos três ideias diferentes
1. Tamanho lógico do arquivo
Quanto conteúdo lógico ele representa.
2. Espaço alocado pelo sistema de arquivos
Quanto do volume está associado ao armazenamento daquele arquivo.
3. Organização física interna do SSD
Como a controladora representa e mantém os dados na NAND.
Misturar esses três níveis gera muita confusão.
Copiar um Sparse File pode fazê-lo crescer?
Dependendo da ferramenta, sistema de arquivos de destino e preservação dos atributos, um arquivo esparso pode perder parte das características que faziam sua representação ocupar pouco espaço.
Exemplo conceitual
Origem:
Tamanho lógico: 100 GB
Alocado: 5 GB
Se uma ferramenta copiar todas as regiões como dados convencionais para um destino que não preserva adequadamente a característica esparsa, o resultado pode consumir muito mais espaço.
Isso explica uma situação aparentemente impossível
Você possui:
20 GB livres
e um arquivo que mostra:
100 GB de tamanho
mas apenas:
5 GB em disco.
Tentar copiá-lo para outro volume pode exigir muito mais que 5 GB.
Não use “Tamanho em disco” sozinho para decidir se uma cópia cabe
Especialmente com:
- sparse files;
- discos virtuais;
- arquivos comprimidos;
- sistemas de arquivos diferentes.
Backup também precisa preservar semântica
Uma boa ferramenta de backup precisa compreender os recursos relevantes do sistema de arquivos quando a preservação dessas características é necessária.
E copiar para FAT32 ou exFAT?
O destino pode não oferecer exatamente os mesmos recursos NTFS.
Por isso, além do espaço, podem existir diferenças em:
- atributos;
- permissões;
- links;
- recursos especiais.
Arquivos comuns normalmente não exigem preocupação
Para:
- fotos;
- vídeos;
- documentos;
- PDFs;
a cópia cotidiana costuma ser simples.
A discussão torna-se mais importante quando lidamos com estruturas avançadas, sistemas, máquinas virtuais e backups.
Diagnóstico: arquivo possui Tamanho em disco muito menor
Se encontrar essa situação, investigue nesta ordem:
1. Verifique compressão
Use propriedades do arquivo e:
compact
2. Verifique se o arquivo possui características especiais
Sparse File é uma possibilidade.
3. Descubra qual programa criou o arquivo
Isso fornece enorme contexto.
4. Identifique o sistema de arquivos
NTFS? exFAT? outro?
5. Não modifique o arquivo antes de entender sua função
Especialmente se pertencer a:
- máquina virtual;
- banco de dados;
- Windows;
- backup;
- aplicação corporativa.
Diagnóstico: pasta parece maior do que o espaço realmente usado
Considere:
- hard links;
- metodologia da ferramenta;
- compressão;
- sparse files;
- permissões.
Diagnóstico: pasta parece menor que o espaço usado pelo volume
Considere também dados que não aparecem facilmente na enumeração convencional:
- arquivos protegidos;
- paginação;
- hibernação;
- restauração;
- snapshots;
- estruturas do sistema.
Não existe uma única causa para diferenças de armazenamento
É justamente por isso que o diagnóstico precisa começar pelo conceito correto.
Regra prática
Se:
Tamanho em disco > Tamanho
pense inicialmente em:
- unidades de alocação;
- grande quantidade de arquivos pequenos;
- tamanho do cluster.
Se:
Tamanho em disco < Tamanho
investigue:
- compressão;
- sparse files;
- características especiais.
Se:
soma das pastas ≠ espaço usado do volume
amplie a investigação para:
- arquivos protegidos;
- estruturas do sistema;
- snapshots;
- hard links;
- metodologia da ferramenta.
E se os números forem absurdamente diferentes?
Não presuma defeito imediatamente.
Colete:
- sistema de arquivos;
- tamanho do cluster;
- quantidade de arquivos;
- atributos;
- compressão;
- origem dos arquivos;
- ferramenta utilizada.
Só depois procure corrupção ou problema de armazenamento.
CHKDSK é necessário?
Não apenas porque:
Tamanho ≠ Tamanho em disco.
Essa diferença é normal.
CHKDSK possui outra finalidade relacionada à verificação do sistema de arquivos.
CrystalDiskInfo resolve isso?
Não.
CrystalDiskInfo ajuda na análise de informações de saúde e SMART do dispositivo.
Ele não existe para explicar a alocação individual dos arquivos pelo NTFS.
CrystalDiskMark?
Também não.
Benchmark mede desempenho.
Não explica por que determinado arquivo utiliza certa quantidade de espaço alocado.
H2testw?
Também possui outra finalidade.
Cada ferramenta responde a uma pergunta diferente.
Um bom diagnóstico começa escolhendo a ferramenta correspondente ao problema.
Como diagnosticar diferenças entre “Tamanho” e “Tamanho em disco” no Windows 11
Depois de entender clusters, slack space, compressão NTFS, Sparse Files, hard links e diferenças entre sistemas de arquivos, podemos transformar tudo isso em um procedimento prático.
O objetivo não é decorar conceitos isolados.
O objetivo é responder perguntas reais como:
- por que uma pasta de 5 GB ocupa 8 GB no SSD?
- por que um arquivo de 100 GB ocupa apenas 12 GB?
- por que os mesmos arquivos ocupam mais espaço em um pendrive?
- por que duas ferramentas mostram tamanhos diferentes?
- por que o SSD mostra mais espaço usado do que a soma das pastas?
- quando devo suspeitar de problema no sistema de arquivos?
- quando a diferença é perfeitamente normal?
Vamos organizar o diagnóstico do mais simples para o mais avançado.
Passo 1: confirme exatamente o que está sendo comparado
Comece abrindo as propriedades do arquivo ou pasta.
Observe:
Tamanho
e:
Tamanho em disco
Não compare um valor mostrado pelo Explorer com outro número de uma ferramenta sem verificar se ambos representam a mesma coisa.
Uma ferramenta pode exibir:
- tamanho lógico;
- tamanho alocado;
- tamanho comprimido;
- espaço exclusivo;
- soma de todos os caminhos encontrados.
Passo 2: veja se o problema acontece em um arquivo ou em uma pasta inteira
Essa diferença muda bastante a investigação.
Se apenas um arquivo apresenta:
Tamanho muito maior que Tamanho em disco
suspeite primeiro de:
- compressão;
- Sparse File;
- estrutura especial criada por algum programa.
Se uma pasta com milhares de arquivos apresenta:
Tamanho em disco muito maior
suspeite primeiro de:
- muitos arquivos pequenos;
- tamanho de cluster;
- sistema de arquivos do volume.
Passo 3: descubra o sistema de arquivos
Abra:
Explorador de Arquivos → Este Computador → clique com o botão direito na unidade → Propriedades
Verifique se o volume utiliza:
- NTFS;
- exFAT;
- FAT32.
Isso importa porque os recursos disponíveis não são iguais.
Passo 4: descubra o tamanho do cluster no NTFS
No Prompt de Comando, podemos consultar:
fsutil fsinfo ntfsinfo C:
Procure:
Bytes Per Cluster
Se aparecer:
4096
temos clusters de:
4 KiB.
Passo 5: compare com outro volume
Se o problema começou depois de copiar os mesmos arquivos para outro dispositivo, compare:
- sistema de arquivos;
- tamanho de cluster;
- quantidade de arquivos;
- tamanho médio dos arquivos.
Isso costuma explicar diferenças grandes em pendrives, HDs externos e cartões.
Cenário 1: pasta pequena ocupa muito mais espaço em disco
Imagine:
Tamanho: 900 MB
Tamanho em disco: 2,1 GB
Verifique primeiro a quantidade de arquivos.
Se existirem:
200.000 pequenos arquivos
a diferença já começa a fazer sentido.
Como confirmar?
Abra as propriedades da pasta e observe:
- número de arquivos;
- número de pastas;
- tamanho total.
Se o conjunto contém arquivos muito pequenos, a alocação por clusters pode explicar boa parte da diferença.
Cenário 2: os mesmos arquivos ocupam mais em um pendrive
Imagine:
SSD interno:
Tamanho em disco: 6 GB
Pendrive:
Tamanho em disco: 10 GB
Os dados podem ser exatamente os mesmos.
A diferença pode estar na unidade de alocação do destino.
Não conclua imediatamente que o pendrive está com defeito
Primeiro verifique:
- sistema de arquivos;
- cluster;
- quantidade de pequenos arquivos.
Cenário 3: um arquivo enorme ocupa muito pouco espaço
Exemplo:
Tamanho: 80 GB
Tamanho em disco: 9 GB
Isso aponta para uma situação muito diferente.
Verifique:
- compressão NTFS;
- arquivo esparso;
- formato do arquivo;
- aplicativo que o criou.
Consultando compressão NTFS
Podemos utilizar:
compact
Para consultar um arquivo ou diretório específico, adapte o comando ao caminho desejado.
O objetivo inicial é identificar se existe compressão, não modificar nada.
O Explorer também ajuda
Nas propriedades avançadas do arquivo ou pasta podemos encontrar:
Compactar o conteúdo para economizar espaço em disco
Se o atributo estiver ativo, a diferença pode ser explicada por compressão NTFS.
Cenário 4: arquivo de máquina virtual
Arquivos como:
.vhd
ou:
.vhdx
merecem atenção especial.
Um disco virtual pode representar uma capacidade lógica grande sem necessariamente consumir imediatamente toda essa capacidade no SSD hospedeiro.
Não interprete apenas pelo número máximo
Se um VHDX representa:
500 GB
isso não significa obrigatoriamente que o arquivo consuma 500 GB naquele momento.
Cenário 5: ferramenta diz que uma pasta tem 30 GB, mas o SSD não perdeu 30 GB
Considere:
- hard links;
- arquivos comprimidos;
- arquivos esparsos;
- metodologia de medição.
Hard links são especialmente importantes
Diferentes nomes podem representar os mesmos dados no NTFS.
Uma ferramenta que simplesmente soma os tamanhos de todos os caminhos pode contabilizar o mesmo conteúdo várias vezes.
Cenário 6: SSD mostra muito espaço usado, mas você não encontra arquivos suficientes
Agora o problema é outro.
Pode existir espaço consumido por:
- pagefile.sys;
- hiberfil.sys;
- restauração do sistema;
- Shadow Copies;
- componentes do Windows;
- arquivos protegidos;
- dados inacessíveis ao usuário comum.
Como não diagnosticar esse caso
Não comece apagando:
C:\Windows
ou:
C:\Windows\WinSxS
manualmente.
Isso pode danificar o sistema.
Cenário 7: diferença surgiu depois de ativar compressão
Se você ativou compressão NTFS, é esperado que:
Tamanho
permaneça semelhante enquanto:
Tamanho em disco
possa diminuir.
Isso não significa corrupção.
Cenário 8: o valor muda quando o arquivo cresce
Um Sparse File ou arquivo dinamicamente expansível pode aumentar gradualmente o espaço alocado conforme recebe dados.
Isso também pode ser normal.
Cenário 9: um ZIP ocupa menos que a soma dos arquivos internos
Normal.
O ZIP pode:
- comprimir os dados;
- transformar muitos arquivos em um contêiner único.
Portanto, não compare diretamente:
soma dos arquivos extraídos
com:
tamanho do ZIP
como se fossem estruturas equivalentes.
Cenário 10: milhares de arquivos pequenos ocupam muito espaço e copiam lentamente
Aqui temos dois efeitos ao mesmo tempo:
- desperdício proporcional de alocação;
- grande quantidade de operações de arquivo.
Esse é um dos motivos pelos quais o volume de arquivos importa tanto quanto o volume em bytes.
Tabela prática de interpretação
| Situação | Causa provável |
|---|---|
| Tamanho em disco maior que Tamanho | Clusters, slack space, muitos arquivos pequenos |
| Tamanho em disco muito menor que Tamanho | Compressão NTFS ou Sparse File |
| Mesmos arquivos ocupam mais em outro volume | Sistema de arquivos ou tamanho de cluster diferente |
| Pasta aparenta ser maior do que o espaço realmente consumido | Hard links ou metodologia da ferramenta |
| SSD mostra mais espaço usado do que a soma das pastas | Arquivos de sistema, snapshots, paginação, hibernação ou permissões |
| Arquivo virtual enorme ocupa pouco espaço | Disco virtual dinâmico ou estrutura esparsa |
| ZIP muito menor que arquivos extraídos | Compressão + contêiner |
| Diferença pequena em arquivo grande | Arredondamento/alocação no último cluster |
10 erros comuns ao analisar “Tamanho em disco”
1. Pensar que é defeito no SSD
A diferença normalmente vem do sistema de arquivos, não do hardware.
2. Confundir cluster com página NAND
São camadas diferentes.
3. Formatar o disco sem diagnóstico
Pode destruir dados sem resolver o problema.
4. Alterar o tamanho de cluster aleatoriamente
Não existe valor perfeito para todos os usos.
5. Apagar WinSxS manualmente
É uma prática arriscada.
6. Comprimir tudo indiscriminadamente
Nem todo tipo de arquivo ganha espaço significativo.
7. Tratar “Tamanho em disco” como uso físico exato da NAND
Não é isso que o Explorer mede.
8. Ignorar hard links
Eles podem distorcer somas de pastas.
9. Assumir que arquivo de 100 GB precisa sempre de 100 GB livres para existir na origem
Sparse Files mostram que a realidade pode ser diferente.
10. Assumir que copiar um arquivo sparse exigirá apenas seu “Tamanho em disco” atual
O destino pode representar o arquivo de outra forma.
Checklist rápido de diagnóstico
Se você encontrou uma diferença estranha, verifique:
- qual é o Tamanho;
- qual é o Tamanho em disco;
- quantos arquivos existem;
- qual é o sistema de arquivos;
- qual é o tamanho do cluster;
- existe compressão NTFS?
- o arquivo é sparse?
- existem hard links?
- os dados vieram de outro volume?
- a ferramenta utilizada entende recursos avançados do NTFS?
Quando a diferença é normal?
Na maioria dos casos.
Pequenas diferenças entre:
Tamanho
e:
Tamanho em disco
fazem parte do funcionamento normal de sistemas de arquivos.
Até diferenças muito grandes podem ser normais quando existem:
- muitos arquivos pequenos;
- compressão;
- sparse files;
- estruturas especiais.
Quando devo investigar mais?
Vale aprofundar quando:
- a diferença surgiu de repente;
- o espaço livre caiu drasticamente;
- arquivos mudaram de comportamento;
- o sistema de arquivos apresenta erros;
- cópias começam a falhar;
- arquivos desaparecem;
- o Windows reporta corrupção;
- o SSD apresenta sinais de falha.
“Tamanho em disco diferente” sozinho não prova corrupção
Esse ponto merece destaque.
Não execute ferramentas de reparo apenas porque os dois números são diferentes.
Essa diferença faz parte do funcionamento normal.
Preciso executar CHKDSK?
Somente se existirem sinais que justifiquem verificar o sistema de arquivos.
Exemplos:
- erros de leitura;
- mensagens de corrupção;
- arquivos inacessíveis;
- inconsistências reais no volume.
Não porque:
Tamanho ≠ Tamanho em disco.
Preciso trocar o SSD?
Também não.
Antes de suspeitar do hardware, verifique os conceitos apresentados neste artigo.
FAQ — Tamanho e Tamanho em disco no Windows 11
Por que Tamanho e Tamanho em disco são diferentes?
Porque o primeiro representa principalmente o tamanho lógico dos dados, enquanto o segundo está relacionado à quantidade de espaço alocado pelo sistema de arquivos.
Um arquivo de 1 byte realmente ocupa 4 KB?
Em uma explicação simplificada de alocação por clusters, ele pode precisar de uma unidade inteira. Porém, NTFS possui mecanismos como dados residentes na MFT que tornam a realidade mais complexa para arquivos muito pequenos.
Por que arquivos pequenos desperdiçam mais espaço?
Porque o espaço é alocado em unidades. Quando o arquivo não utiliza completamente a última unidade, sobra uma área que não é aproveitada como conteúdo daquele arquivo.
O que é slack space?
É o espaço não utilizado dentro da última unidade de alocação associada a um arquivo.
Quanto maior o cluster, maior o desperdício?
Pode ser, especialmente em volumes com grande quantidade de arquivos pequenos.
Cluster pequeno é sempre melhor?
Não. A escolha envolve compromissos e depende do uso do volume.
Por que o mesmo arquivo ocupa valores diferentes em dois discos?
Os volumes podem utilizar sistemas de arquivos ou unidades de alocação diferentes.
O SSD elimina o conceito de cluster?
Não. O sistema de arquivos continua utilizando unidades de alocação mesmo quando o armazenamento físico é um SSD.
Cluster é a mesma coisa que página NAND?
Não. Cluster pertence à organização lógica do sistema de arquivos. Página NAND pertence à arquitetura interna do SSD.
O que é compressão NTFS?
É um recurso do NTFS que permite armazenar determinados dados de forma comprimida enquanto os aplicativos acessam o conteúdo de maneira transparente.
Compressão NTFS muda o Tamanho do arquivo?
O tamanho lógico pode permanecer igual enquanto o Tamanho em disco diminui.
O que é Sparse File?
É um arquivo que pode possuir grandes regiões lógicas sem precisar alocar armazenamento convencional para todas elas.
Um arquivo de 100 GB pode ocupar somente 10 GB?
Sim, em determinados cenários envolvendo sparse files, compressão ou estruturas especiais.
Sparse File é igual a ZIP?
Não.
Sparse File é igual a compressão NTFS?
Também não.
O que são hard links?
São múltiplos nomes que podem se referir aos mesmos dados de arquivo no NTFS.
Hard links podem fazer uma pasta parecer maior?
Sim. Algumas ferramentas podem somar os mesmos dados mais de uma vez se não tratarem hard links corretamente.
Por que o WinSxS parece tão grande?
Uma das razões históricas para medições confusas envolve componentes compartilhados e hard links. O Component Store deve ser administrado pelas ferramentas apropriadas do Windows, não por exclusão manual.
Posso apagar arquivos do WinSxS para liberar espaço?
Não é recomendável apagar manualmente arquivos dessa pasta.
Por que meu pendrive usa mais espaço que meu SSD?
Uma possibilidade é o tamanho de cluster do sistema de arquivos usado no pendrive, especialmente se você copiou milhares de arquivos pequenos.
FAT32, exFAT e NTFS usam o espaço da mesma forma?
Não. Eles possuem estruturas, recursos e comportamentos diferentes.
Formatar o pendrive com outro cluster resolve?
Pode alterar o consumo de espaço, mas não deve ser feito sem avaliar finalidade, compatibilidade e backup.
Por que ZIP pode economizar espaço mesmo sem comprimir muito?
Porque transforma muitos arquivos independentes em um único contêiner, reduzindo parte do impacto da alocação individual no sistema de arquivos externo.
Tamanho em disco mostra exatamente o que está gravado fisicamente na NAND?
Não.
Ele representa uma visão do espaço alocado no sistema de arquivos, não um mapa físico das células do SSD.
CrystalDiskInfo mostra Tamanho em disco?
Não é essa a finalidade principal da ferramenta.
CrystalDiskInfo é voltado à análise das informações de saúde do dispositivo e SMART.
CrystalDiskMark ajuda a descobrir isso?
Não. Ele mede desempenho de armazenamento.
CHKDSK corrige diferença entre Tamanho e Tamanho em disco?
Essa diferença normalmente não é um erro para ser corrigido.
Por que uma pasta com milhões de arquivos demora tanto para calcular?
Porque o Windows precisa enumerar uma quantidade enorme de objetos e seus metadados.
Por que duas ferramentas mostram números diferentes?
Elas podem medir conceitos diferentes ou tratar hard links, compressão, arquivos esparsos e permissões de maneiras diferentes.
Como saber se existe compressão NTFS?
Você pode verificar as propriedades avançadas do arquivo ou utilizar o comando:
compact
Como consultar o tamanho do cluster no NTFS?
Use:
fsutil fsinfo ntfsinfo C:
e procure a informação:
Bytes Per Cluster
Conclusão
Quando o Windows 11 mostra valores diferentes em:
Tamanho
e:
Tamanho em disco
isso não significa que o sistema esteja errando a conta.
Os dois campos respondem a perguntas diferentes.
O tamanho lógico descreve quanto conteúdo o arquivo representa.
O espaço alocado depende da maneira como o sistema de arquivos armazena esse conteúdo.
Clusters ajudam a explicar por que milhares de arquivos pequenos podem ocupar proporcionalmente mais espaço.
Compressão NTFS e Sparse Files explicam por que um arquivo pode possuir um tamanho lógico enorme, mas consumir muito menos armazenamento.
Hard links mostram por que simplesmente somar todos os caminhos encontrados também pode produzir números enganosos.
E o ponto mais importante:
NTFS e SSD não são a mesma camada.
O Explorer mostra a visão lógica do sistema de arquivos. A controladora do SSD administra internamente NAND, páginas, blocos, wear leveling e outras estruturas que não aparecem diretamente nas propriedades de um arquivo.
Por isso, antes de formatar um disco, executar ferramentas de reparo ou suspeitar de defeito no SSD, descubra primeiro:
o que está sendo medido.
Essa pequena mudança de abordagem evita muitos diagnósticos errados.
Precisa descobrir por que seu SSD está sem espaço?
A VMIA – Manutenção e Configuração realiza diagnóstico de computadores Windows, armazenamento, SSDs, desempenho, arquivos, backups e problemas relacionados ao sistema operacional.
O atendimento pode incluir análise da causa do consumo de armazenamento, identificação de arquivos e pastas que cresceram, diagnóstico de desempenho do SSD e verificação das configurações do Windows.
VMIA – Manutenção e Configuração
Rua Prof. Sud Menucci, 291 – Vila Mariana – São Paulo – SP – 04017-080
WhatsApp/Telefone: (11) 99779-7772
Site oficial: vmia.site
Blog técnico: vmia.com.br
Atendimento com agendamento.
Faça um comentário