Por que existe uma diferença tão grande entre "Tamanho" e "Tamanho em disco"?

302

Como você pode ver abaixo, há muita diferença entre os campos Tamanho e Tamanho no disco da minha pasta. Por que é que?

Captura de tela mostrando 50.875 arquivos em 1.504 pastas, 105 MB sendo 1,43 GB no disco

Eu sei que o tamanho do disco deve ser um pouco mais do que o tamanho por causa das unidades de alocação no Windows, mas por que tanta diferença? Poderia ser por causa do grande número de arquivos?

BTW, esta pasta está no cartão SD do meu telefone Android. Dentro disso, meu aplicativo de mapas armazena seus mapas em cache e o aplicativo obtém seu mapa do Google Maps.

vfsoraki
fonte
10
Olá thelastblack, e bem-vindo ao SuperUser. Editei sua pergunta para remover a parte sobre desfragmentação, pois as duas respostas existentes se concentram no tamanho / tamanho da discrepância de disco e o formato Stack Exchange funciona melhor quando cada pergunta postada é sobre uma única coisa. Você certamente pode pedir novamente isso como uma pergunta separada, embora eu ache que as respostas que você recebeu até agora sobre essa pergunta mostram que a desfragmentação não o ajudará. (Geralmente, também não é bom em mídias de estado sólido.) Sinta-se à vontade para editar sua pergunta mais, se achar que mudei de intenção de alguma maneira.
um CVn
1
@ MichaelKjörling Heh, eu apenas editado em uma discussão menor em fragmentação (se distraiu um pouco mais cedo)
Bob
21
@ MichaelKjörling Não edite perguntas retroativamente para ajustar as respostas. Uma das respostas aborda a parte de fragmentação da pergunta do OP. Sua edição precisa ser revertida para evitar confusão.
DanteTheEgregore
5
@DanteTheEgregore Se você está se referindo à resposta de Bob, que de fato foi editada para discutir também os efeitos da fragmentação, antes de pular a arma, verifique os históricos de edição e os carimbos de data e hora dessa resposta e da pergunta. No momento da minha edição, a resposta de Bob não cobria a questão da fragmentação. Se o OP quiser fazer isso, editar novamente "desfragmentar a mídia me ajudará com isso?" deve resolver qualquer confusão pendente, embora eu ainda ache melhor perguntar como uma pergunta separada; Na IMO, a questão da diferença entre os dois valores não tem relação.
um CVn
11
Parece-me que este aplicativo está seriamente mal programado - considere arquivar um relatório de bug. Não sou de forma alguma um programador profissional, mas uma vez hackeei algo semelhante no JavaME, e é claro que um dos problemas que tive que resolver foi como armazenar todos esses pequenos blocos de mapa com eficiência (armazenamento e acesso) em um contêiner. Acabei usando arquivos zip não compactados.
A. Donda

Respostas:

303

Eu assumirei que você está usando o sistema de arquivos FAT / FAT32 aqui, já que você mencionou que este é um cartão SD. NTFS e exFAT se comportam de maneira semelhante em relação às unidades de alocação. Outros sistemas de arquivos podem ser diferentes, mas eles não são suportados no Windows de qualquer maneira.

Se você possui muitos arquivos pequenos, isso certamente é possível. Considere isto:

  • 50.000 arquivos.

  • Tamanho do cluster de 32 kB (unidades de alocação), que é o máximo para o FAT32

Ok, agora o espaço mínimo ocupado é de 50.000 * 32.000 = 1,6 GB (usando prefixos SI, não binários, para simplificar a matemática). O espaço que cada arquivo ocupa no disco é sempre um múltiplo do tamanho da unidade de alocação - e aqui assumimos que cada arquivo é realmente pequeno o suficiente para caber em uma única unidade, com algum espaço (desperdiçado) sobrando.

Se cada arquivo tivesse uma média de 2 kB, você obteria cerca de 100 MB no total - mas também estará gastando 15x isso (30 kB por arquivo) em média devido ao tamanho da unidade de alocação.


Explicação detalhada

Por que isso acontece? Bem, o sistema de arquivos FAT32 precisa acompanhar onde cada arquivo está armazenado. Se fosse para manter uma lista de todos os bytes, a tabela (como um catálogo de endereços) aumentaria na mesma velocidade que os dados - e gastaria muito espaço. Então, o que eles fazem é usar "unidades de alocação", também conhecidas como "tamanho do cluster". O volume é dividido nessas unidades de alocação e, no que diz respeito ao sistema de arquivos, elas não podem ser subdivididas - esses são os menores blocos que podem ser endereçados. Muito parecido com o número da sua casa, mas o carteiro não se importa com quantos quartos você tem ou quem mora neles.

Então, o que acontece se você tiver um arquivo muito pequeno? Bem, o sistema de arquivos não se importa se o arquivo é 0 kB, 2 kB ou até 15 kB, ele oferece o mínimo de espaço possível - no exemplo acima, isso é 32 kB. Seu arquivo está usando apenas uma pequena quantidade desse espaço e o restante é basicamente desperdiçado, mas ainda pertence ao arquivo - como um quarto que você deixa desocupado.

Por que existem diferentes tamanhos de unidades de alocação? Bem, torna-se uma troca entre ter uma tabela maior (catálogo de endereços, por exemplo, dizer que John é dono de uma casa na 123 Fake Street, 124 Fake Street, 666 Satan Lane, etc.) ou mais espaço desperdiçado em cada unidade (casa). Se você tiver arquivos maiores, faz mais sentido usar unidades de alocação maiores - porque um arquivo não recebe uma nova unidade (interna) até que todas as outras estejam preenchidas. Se você tiver muitos arquivos pequenos, bem, você terá uma tabela grande (catálogo de endereços) de qualquer maneira, assim também poderá fornecer-lhes pequenas unidades (casas).

As grandes unidades de alocação, como regra geral, desperdiçarão muito espaço se você tiver muitos arquivos pequenos. Geralmente, não há um bom motivo para ultrapassar 4 kB para uso geral.


Fragmentação?

Quanto à fragmentação, a fragmentação não deve desperdiçar espaço dessa maneira. Arquivos grandes podem ser fragmentados, ou seja, divididos em várias unidades de alocação, mas cada unidade deve ser preenchida antes que a próxima seja iniciada. A desfragmentação pode economizar um pouco de espaço nas tabelas de alocação, mas esse não é o seu problema específico.


Soluções possíveis

Como o gladiator2345 sugeriu , suas únicas opções reais nesse momento são conviver com ele ou reformatar com unidades de alocação menores.

Seu cartão pode estar formatado em FAT16, que tem um limite menor no tamanho da tabela e, portanto, requer unidades de alocação muito maiores para endereçar um volume maior (com um limite superior de 2 GB com unidades de alocação de 32 kB). Fonte cortesia de Braiam . Se for esse o caso, você poderá formatar com segurança como FAT32 de qualquer maneira.

Prumo
fonte
3
O espaço desperdiçado devido aos tamanhos mínimos de alocação é, na verdade, tecnicamente chamado de "fragmentação interna"; portanto, você pode dizer que a fragmentação é a culpada. Mas ainda não é algo que qualquer ferramenta de "desfragmentação" possa fazer.
Hbbs
3
(Menos tecnicamente, é chamado apenas de "folga".)
hobbs
1
Os tamanhos de cluster também limitam o tamanho máximo do sistema de arquivos. Por exemplo, se seu espaço de endereço for de 32 bits, você terá um total de ~ 4,29 bilhões de clusters possíveis. Agora, se você usar o menor tamanho de cluster suportado pelo NTFS (512 bytes), poderá endereçar um máximo de 512 * 2 ^ 32 bytes = 2 GiB. Se você precisar de um volume que possa armazenar mais de 2 GiB de dados, precisará aumentar o tamanho do cluster. Isso tudo é independente do maior arquivo real que você tenta armazenar, desde que você não possa armazenar um arquivo maior que 2 GiB que seja o menor dos seus problemas.
precisa saber é o seguinte
Os 4 clusters KiB permitem endereçar arquivos em um volume com tamanho de até 16 TiB, o que deve ser suficiente para o futuro próximo.
Andon M. Coleman
1
Bem, ele poderia compactar seu arquivo de arquivos pequenos em um arquivo grande.
Einpoklum
45

Essa é uma daquelas situações em que a compactação / arquivamento em um único arquivo pode ajudar. O que Bob disse em sua resposta é verdadeiro, mas a solução pode ser mais fácil do que reformar o disco, como sugerem outras respostas. Se você compactar ou arquivar o diretório (usando zip, tar ou qualquer outro método), o sistema de arquivos verá que você tem um único arquivo grande, em vez de vários menores. Mesmo sem compactar, você receberá quase 1,4 GiB de espaço, porque todos esses "arquivos pequenos" serão contados como um único arquivo grande.

Dentro disso, meu aplicativo de mapas armazena seus mapas em cache e o aplicativo obtém seu mapa do Google Maps

Talvez você deva discutir com o desenvolvedor o uso de um arquivo ou banco de dados em vez de vários arquivos. Isso provavelmente também ajudará a ter o disco menos fragmentado e certamente economizará espaço, especialmente se for uma unidade flash NAND. Se você explicar a situação ridícula em que 100 MB de carga útil / dados úteis se tornam 1.4GiB, há algo errado com a forma como os dados são armazenados, e os desenvolvedores devem trazer uma solução melhor.

Braiam
fonte
1
> Dentro disso, meu aplicativo de mapas armazena seus mapas em cache e o aplicativo obtém seu mapa do Google Maps. - infelizmente, nesse caso, a compactação (que é efetivamente um sistema de arquivos acima do básico) exigiria suporte desse aplicativo de mapeamento.
Bob
1
@Bob então a solução deve vem do lado desenvolvedor D:
Braiam
4
Isso é totalmente verdade. Por enquanto, devo mudar meu aplicativo.
precisa saber é o seguinte
17
@Braiam Não está enganando o sistema de arquivos, pensando que há apenas um arquivo; não é apenas um arquivo. Quanto ao motivo pelo qual os desenvolvedores não armazenam as informações do cache em um arquivo morto, provavelmente é porque a maioria dos formatos de arquivo morto não foi projetada para gravações aleatórias rápidas, das quais um cache certamente precisa. Uma alternativa melhor pode ser usar uma biblioteca de banco de dados leve como o SQLite.
usar o seguinte comando
1
Absolutamente verdadeiro ..... +1
arundevma
25

Caso alguém seja confrontado com esse problema, pode ser útil saber também que outro motivo para ver grande diferença no tamanho / espaço do arquivo no disco é o uso de fluxos de dados alternativos (ADS)

Isso se aplica apenas ao NTFS ao meu conhecimento. Os ADS são conhecidos por usos legítimos e não legítimos:

  • marcar um arquivo como baixado da Internet
  • armazenar metadados (a Microsoft queria incluir alguns dos recursos do Apple OS, como não usar extensão de arquivo para determinar o tipo de arquivo)
  • ocultar dados ou códigos no contexto de um malware .

ADS simplesmente: qualquer arquivo NTFS pode conter vários fluxos de dados (entenda "subarquivos"). Um é o fluxo principal, usado pelo Windows Explorer e outras ferramentas do Windows, que contém o conteúdo usual de um arquivo. Os fluxos de dados alternativos podem conter outras informações, exatamente como o fluxo principal, mas não podem ser manipulados diretamente pelas ferramentas do Windows (em particular, o Explorer exibe o tamanho do arquivo igual ao tamanho do fluxo principal, independentemente do tamanho do ADS), você precisa usar ferramentas ou códigos especializados para escrever, ler e localizar ADS.

O ponto principal é que, no caso de grande diferença de tamanho de arquivo observada, não negligencie a possibilidade de ADS e malware oculto.

Outro link .

Para experimentar com segurança o ADS, tente isso no nível do DOS / CMD ...

Crie e, em seguida, exiba o conteúdo de um arquivo na raiz de C:

C:\> echo The main data stream> test.txt
C:\> type test.txt

Resultado:

C:\> The main data stream

Agora adicione um ADS com o mesmo método, basta especificar o nome do ADS além do nome do arquivo:

C:\> echo The secret message> test.txt:secret

Você acabou de ocultar a mensagem secreta no arquivo. Observe que o tamanho do arquivo no Explorer não mudou, apesar de termos adicionado bytes no "segredo" do ADS.

Tente exibir o conteúdo do ADS:

C:\> type test.txt:secret

Resultado:

The filename, directory name, or volume label syntax is incorrect.

O CMD typenão pode exibir o conteúdo do ADS. Em vez disso, usaremos o Bloco de notas:

notepad test.txt:secret

No bloco de notas, podemos ver o conteúdo do ADS:

The secret message

Você também pode ocultar um executável completo em um ADS de um arquivo de texto inocente e executá-lo a qualquer momento. A riqueza não prejudica os hackers :-)

min
fonte
Eu não sou um vencedor, meu trabalho é feito principalmente no Linux. Isso foi muito útil. Obrigado
vfsoraki
4
Vale a pena usar uma ferramenta como o Streams da Sysinternals para verificar o uso de ADS. Por exemplo, os arquivos baixados em um sistema Windows podem ser marcados com uma fonte no ADS, embora seja pequeno e não ocupe espaço. Ele não será exibido na saída dir ou Explorer normalmente. Isso pode ocupar blocos e agravar o problema de uso do disco que você está investigando. .
Adr
19

O problema pode ser devido ao tamanho do cluster.

De acordo com a Microsoft :

Se você não estiver usando a compactação NTFS para nenhum arquivo ou pasta contido no volume, a diferença entre TAMANHO e TAMANHO NO DISCO é desperdício de espaço devido a um tamanho de cluster maior que o necessário. Você deve tentar usar um tamanho de cluster ideal para que o valor SIZE ON DISK seja o mais próximo possível do valor SIZE. Uma discrepância excessiva entre o tamanho do TAMANHO NO DISCO e o tamanho do TAMANHO é uma indicação de que o tamanho padrão do cluster é muito grande para o tamanho médio do arquivo que você está armazenando no volume e que deve ser diminuído. Isso pode ser feito apenas fazendo backup do volume e reformatando o volume usando o comando format e a opção / a para especificar o tamanho de alocação apropriado: IE: format D: /a:2048 (Este exemplo usa um tamanho de cluster de 2 KB).

Tente formatar sua unidade com um tamanho de cluster menor.

arundevma
fonte
4
Dito isto, não se deve tornar o tamanho do cluster menor que 4096 bytes ou simplesmente não múltiplo desse número. O SO de 32 bits funciona com páginas que (no caso não PAE) têm 4096 bytes, portanto, o uso de clusters não múltiplos pode afetar negativamente o desempenho do sistema de arquivos. É por isso que o tamanho padrão é definido como 4096 bytes.
Ruslan
2
Para adicionar o que @Ruslan disse, os discos rígidos mais novos agora têm um tamanho de setor de 4 kB e seria ideal alinhar o sistema de arquivos aos setores físicos e ter um múltiplo do tamanho do setor físico como o tamanho da unidade de alocação.
Bob
1
@Ruslan Eu acredito que você quer dizer que deve ser uma potência de duas vezes 4096. 12288 (3 × 4096) e 20480 (5 × 4096) não são ótimas opções.
Scott Scott
9

Vejo muitas pessoas recomendando reformatar sua unidade com um tamanho de cluster menor. Como este é um cartão SD, observe que muitos fornecedores pré-formatam o cartão para o tamanho recomendado do cluster para corresponder ao tamanho do tamanho do cluster da NAND (manter os dois em sincronia é muito importante para otimizar o desempenho de leitura / gravação e reduzir o desgaste)

Você não pode alterar o tamanho do cluster do NAND (é um atributo físico do hardware do seu cartão SD).

Primeiro, execute o scandisk / chkdsk no seu cartão SD para garantir que o problema do relatório de tamanho não esteja dentro de um sistema de arquivos corrompido.

Segundo, sugiro que você relate o bug aos desenvolvedores do Google Map, por eles serem os culpados aqui. Eles devem estar usando um método de armazenamento superior. A correção também deve fazer com que o aplicativo seja executado mais rapidamente em muitos dispositivos devido à menor atividade de E / S e do driver do sistema de arquivos.

Matias N Goldberg
fonte
Na verdade, não era o Google Maps, mas outro aplicativo usando os mapas do Google. Informei o desenvolvedor e acabei de remover esses arquivos do meu SD.
precisa saber é o seguinte
7

Este é um problema geral com muitos sistemas de arquivos. Existem dois fatores em ação aqui: o número máximo de "blocos" que um sistema de arquivos pode manipular por volume lógico e restrições físicas do meio de armazenamento. Apenas um arquivo pode ser alocado para qualquer bloco (os arquivos geralmente levam quantos blocos forem necessários). Portanto, um arquivo de texto com 64 bytes geralmente pode levar de 4k a 32k, dependendo do tamanho do bloco do sistema de arquivos em que ele reside.

Uma maneira de pensar sobre isso é pensar em cada bloco no sistema de arquivos como uma caixa e o sistema de arquivos como uma sala. Todas as suas caixas têm o mesmo tamanho e você tenta encaixar o máximo possível em uma sala. Se você encaixar todos eles com mais espaço sobrando, precisará obter caixas maiores para que a sala fique completamente cheia de caixas.

Uma das regras para colocar as coisas em caixas é que você não pode colocar duas coisas não relacionadas em uma caixa. Eles precisam fazer parte do mesmo documento. Então, se eu digitar uma página de texto, ela terá sua própria caixa. Se meu texto digitado tivesse tantas páginas que eu não pudesse encaixar tudo em uma caixa, eu simplesmente encontraria outra caixa e continuaria colocando as páginas ali, repetindo até que eu arquivasse todas as minhas páginas. Eu também teria anotado as caixas que usei para esse documento e a ordem das caixas para lê-lo em sequência.

Dependendo de como eu organizaria as caixas, posso ter apenas espaço suficiente no meu manifesto para um determinado número de caixas. Portanto, se eu tivesse uma sala grande para preencher, mas apenas um pequeno número de caixas, teria que usar caixas muito grandes para atingir a capacidade da sala.

Portanto, nesse caso, meu documento de uma página ainda ocuparia uma única caixa, com mais nada compartilhando-o.

As mesmas situações ocorrem entre várias soluções de armazenamento. O FAT32 pode gerenciar apenas o que é considerado um número baixo de "caixas" nos enormes discos rígidos de hoje, e acaba com "caixas" muito grandes para compensar isso.

CyberSkull
fonte
6

Além dos tamanhos de cluster, você também pode ter uma discrepância devido às seguintes condições:

  • Arquivos compactados ou criptografados podem ocupar um espaço diferente do tamanho do arquivo lógico.
  • Os arquivos vinculados reportam n vezes o número de links vezes o tamanho do arquivo para o tamanho lógico do arquivo, mas o espaço físico usado geralmente é menor.
Archimedes Trajano
fonte
Geralmente, isso pode ser verdade. Mas no meu caso, a alta unidade de alocação foi o problema.
precisa saber é o seguinte
3
Sim, estou apenas tentando adicionar à resposta, dando mais motivos possíveis para a discrepância.
Archimedes Trajano
6

Você deve dar uma olhada na entrada Block Suballocation na Wikipedia. É exatamente isso que está acontecendo com você. O uso de um sistema de arquivos com suporte para Tail Packaging é uma solução no nível do sistema de arquivos para esse problema, além de alterar o tamanho do cluster de alocação.

Todos têm o inconveniente de precisar reformatar o disco.

Em alguns casos, apenas o armazenamento desses arquivos em um arquivo solucionaria o problema (e os arquivos pequenos também seriam compactados ao lado de parar de perder espaço no final dos arquivos). Isso tem o inconveniente de gastar algum tempo para descompressão.

Outra opção se você tiver tantos arquivos pequenos por causa de algum problema específico relacionado ao aplicativo é armazenar os dados do software usando outro método (pode estar em um banco de dados). Mas é claro que é uma solução para programadores, não para usuários finais.

http://en.wikipedia.org/wiki/Tail_packing

kriss
fonte
0

Observei enormes discrepâncias de tamanho de arquivo no Windows 10 em um arquivo individual, mas se eu olhar as propriedades do mesmo arquivo do mesmo local (uma unidade de rede), no Windows XP, a grande discrepância não existe; apenas uma pequena diferença, que é o que você esperaria. Acho que existe um bug no Windows 10. Um arquivo com 449 MB provavelmente não ocupa 3,99 GB, que é o que o Windows 10 está me dizendo.

David Hutchins
fonte
1
Apenas um FYI, a questão não tem nada a ver com o Windows 10. OP está usando o Windows 7.
TheKB