Por que a compactação NTFS ocupa muito espaço?

7

Para economizar espaço em disco, imaginei que seria uma boa ideia compactar o VMware vSphere Client que eu instalei porque quase nunca o uso.

Fiquei surpreso ao descobrir que ele tinha exatamente o efeito oposto no espaço livre em disco. Eu o rastreei e descobri que está relacionado a compactar a pasta Help . A perda de espaço em disco não é refletida no tamanho da pasta.

Eu repeti o ciclo compress / descomprimir três vezes para garantir que outro programa não coincidentemente ocupasse o espaço em disco. Pode ser notável que a pasta contenha um grande número de arquivos pequenos (≈ 30k).

Por que isso acontece e posso de alguma forma encontrar outras pastas que eu deveria descompactar para economizar espaço em disco?

Sem compressão:

Com a compactação:

    
por AndreKR 08.06.2013 / 22:44

3 respostas

8

Um pouco de conhecimento sobre as capturas de tela do tamanho da pasta que você forneceu:

Descomprimido

Como esperado com muitos arquivos pequenos, há muita sobrecarga. Seu disco rígido é particionado com um determinado tamanho de bloco - 4KB por padrão para NTFS.

Cada arquivo tem que alocar um múltiplo de 4KB, ou seja, não importa se você tem um arquivo de 1 KB ou de 3,5 KB, ambos ocuparão 4 KB de espaço. Se você tiver um arquivo de 13 KB, ele usará 16 KB na sua unidade. A diferença entre "Tamanho" e "Tamanho no disco" é a sobrecarga introduzida pelo espaço não utilizado em blocos, as chamadas dicas de cluster .

Comprimido

Após a compactação, "Tamanho" ainda é o mesmo que a quantidade de dados da rede não foi alterada. No entanto, a compactação foi capaz de reduzir o tamanho total de cerca de 130MB. Na verdade, ainda mais porque a sobrecarga aqui também se aplica. Portanto, a compactação realmente economizou espaço nessa pasta e isso também é exibido no tamanho da pasta.

Agora, em relação ao comportamento que você vê com o espaço livre em disco reduzido na unidade C: Isso pode ter vários motivos. Uma coisa é entender que o espaço livre em disco sempre será menor que

<Disk size> - <total size of all files>

Isso ocorre porque há muitos metadados que também consomem espaço (instantâneos VSS, pontos de restauração do sistema, MFT e assim por diante).

Durante a compactação de arquivos únicos, o NTFS manterá temporariamente o arquivo original até a conclusão da compactação. Isso é para garantir que você ainda teria uma versão válida do arquivo caso o computador travasse. Isso, no entanto, deve ser apenas temporário. No entanto, tudo aponta para metadados NTFS para causar isso.

Para verificar com mais precisão os resultados, você pode fazer o seguinte:

  • Comece com uma pasta descompactada
  • Desative a Proteção do sistema para cada volume (Propriedades do computador / Proteção do sistema)
  • Exclua os pontos de restauração de cada volume na mesma caixa de diálogo
  • Use "Limpeza de disco" nas propriedades do seu volume C: para remover arquivos temporários
  • Anote o espaço livre em disco
  • Compacte a pasta
  • Reinicie seu computador
  • Use a limpeza de disco novamente
  • Verifique o espaço livre no seu disco

Em teoria, você deve ser capaz de ver um aumento no espaço livre

    
por 09.06.2013 / 00:58
3

Tendo pesquisado recentemente um problema semelhante, também posso dizer que um arquivo compactado leva pelo menos 4 kilobytes de espaço por arquivo e um espaço temporário de 64 kilobytes, que é o tamanho de uma "Unidade de compactação" para NTFS com 4kb tamanho do cluster. O artigo no blogs.msdn.com também menciona que quando o arquivo é compactado, o espaço em disco é alocado para manter uma CU completa e é liberado em tempo indeterminado. Esta deve ser a razão pela qual você está experimentando a perda de 5 GB, ainda que temporária (uma reinicialização deve definitivamente consertar essa perda, alguns outros meios devem fazer isso também, mas não defrag - tentei e falhei). Aparentemente, o que é alocado parece ser muito maior (64kb * (31048 + 582) = 2072903680 ou 1,93 GB), mas isso é explicável, pois o NTFS tem transações que levam tempo e unidades do processador para serem confirmadas em dados brutos, e quando esse processo terminado, você obterá todos os 5 GB mais 150 MB de espaço liberado devido à compressão de volta.

Para resumir, você só perde espaço temporariamente se comprimir muitos arquivos. Mas, se esses arquivos forem modificados com freqüência, seu espaço em disco será alocado para conter dados descompactados para esses arquivos caso o conteúdo alterado não possa ser compactado para caber no espaço que o cluster ocupou antes da ação de gravação.

    
por 24.11.2014 / 16:18
1

Eu tive os mesmos fenômenos:

Migração do servidor, copiei as pastas de dados de uma unidade do antigo Windows Server 2012R2 (com 2 pastas compactadas) em uma unidade do Windows Server 2016 Datacenter mais recente do mesmo tamanho em que criei a estrutura de pastas e configurei os sinalizadores compactados essas duas pastas anteriormente ao processo de cópia. Durante a cópia, fiquei sem espaço em disco, e em qualquer lugar que eu olhei, apenas 3GB de 20GB são usados, mas a própria unidade me diz que 19.x GB são usados. Um colega me disse para remover o sinalizador de compressão, e milagrosamente os 17GB perdidos reaparecem.

Depois, li seu artigo e decidi reaplicar o sinalizador e tentar reiniciar, mas o espaço em disco usado não aumentou dessa vez.

Eu acho que poderia haver um problema no Windows Server 2016 (talvez desde sempre) que arquivos temporários gerados internamente não são limpos corretamente quando os arquivos são copiados para uma pasta compactada (em oposição a quando o sinalizador de compactação é aplicado a já existente arquivos).

    
por 07.11.2018 / 15:25

Tags