De onde vem o tamanho do arquivo, ou seja, como ls e cp sabem o tamanho do arquivo?

Question

Recentemente eu tive um arquivo que relatou um tamanho de arquivo de 33P bytes no meu SSD de 500GB, mais detalhes aqui . Isso foi por meio de ls e cp relataria que não havia espaço suficiente.

Em meu curto conhecimento e pouco entendimento do VFS, acredito que os drivers (SATA) falem com o disco e ele percorra o VFS até chegar aos inodes (suposição da descrição na seção 8.6 Inodes aqui ) e então o kernel de alguma forma passa para o espaço do usuário.

No final, gosto de saber como ls e cp sabem o tamanho, mas também gostaria de saber como um arquivo poderia informar o tamanho errado e se isso aconteceria novamente no futuro, onde procurar respostas.

    

Answer 1

strace -v -e trace=lstat ls -l file
[...]
lstat("tw.txt", {[...] st_size=1103, [...]

    

Answer 2

O tamanho de um arquivo é armazenado como parte dos metadados do arquivo , junto com o tipo de arquivo (diretório / regular / symlink /…), os timestamps, as permissões, etc. Os aplicativos recuperam esses metadados com a stat chamada de sistema . Os metadados são armazenados no inode do arquivo.

O driver SATA está envolvido se o arquivo estiver armazenado em um disco SATA, mas esse é um nível muito inferior ao do sistema de arquivos. Levar em conta o nível SATA não ajudará você a entender o que está acontecendo, pelo contrário.

É possível que um arquivo seja maior que o disco. Um arquivo pode ser compactado. A maioria dos sistemas de arquivos suporta apenas uma forma muito simples de compactação: arquivos esparsos , em que grandes blocos de bytes nulos não são armazenados no disco . O uso do disco relatado por du não conta esses blocos omitidos, mas o tamanho do arquivo relatado por ls é.

Como Wumpus Q. Wumbley observa em um comentário, o tamanho que você encontrou (36028797019011568) é um pouco fora de ser um tamanho perfeitamente razoável (47600). Portanto, é provável que, em vez de ser um arquivo esparso legítimo, esse tamanho seja um sinal de corrupção de dados no disco. Antes de fazer qualquer outra coisa, execute um teste de memória . A RAM é a maior fonte de erros de bit único não corrigidos. Tenha em atenção que é provável que tenha dados mais corrompidos devido a este erro.