EXT3: Se o tamanho do bloco é 4K, por que ls -l mostra os tamanhos de arquivo abaixo disso?
Se você executar ls -l em um arquivo que contenha uma letra, ele será listado como tamanho 2B. Se o seu sistema de arquivos estiver em blocos de 4k, pensei em arredondar os arquivos para o tamanho do bloco? É porque ls -l realmente lê a contagem de bytes do inode? Em que circunstâncias você é arredondado para bloquear respostas versus respostas reais de contagem de bytes nos utilitários Linux 2.6 Kernel GNU?
Lembre-se de que o ext4 introduz um conceito de "empacotamento de arquivos pequenos", pelo que um arquivo pequeno ocupará o mesmo bloco de disco que seu inode ocupa (e, portanto, evitará desperdiçar blocos de disco): lwn.net/Articles/469805
Eu acho que você inseriu essa letra no arquivo com echo a > fileou vim file, o que significa que você terá essa letra e uma nova linha adicional (dois caracteres, portanto, dois bytes). ls -lmostra o tamanho do arquivo em bytes, não em blocos (para ser mais específico: comprimento do arquivo ):
(observe que cat -Aexibe novas linhas como $caractere)
Em contraste com ls -l, dumostrará o tamanho real ocupado no disco:
(na verdade, dumostra o tamanho em unidades de 1 kB, então aqui o tamanho é de 4 × 1024 bytes = 4096 bytes = 4 kiB, que é o tamanho do bloco neste sistema de arquivos)
Para lsmostrar isso, você precisará usar a -sopção em vez de / além de -l:
A primeira coluna é o tamanho alocado, novamente em unidades de 1kiB. O último pode ser alterado especificando --block-size, por exemplo
Além disso, é bom ter as duas informações. Os sistemas de arquivos podem fazer "compactação de cauda" (sp?) (Use um bloco compartilhado entre arquivos curtos), "copiar na gravação" e "perfuração" ... tornando o relacionamento do tamanho do arquivo <-> espaço em disco um complexo.
— Rmano 28/04
Eu acho que a resposta profunda é a seguinte:
O comprimento do arquivo lógico e o espaço em disco ocupado são coisas realmente diferentes.
Como as outras respostas mostram, em princípio, um arquivo criado com dois bytes possui dois bytes (show by ls -l) e ocupa 4 KiB (show by duou ls -ls).
Ok, testtem comprimento 1 e tamanho (em disco) 4 KiB. Mas:
(o primeiro comando adiciona 8191 zero bytes a test), agora o teste tem comprimento 8192, mas ainda ocupa 4 KiB no disco (ele possui um "furo") nele (1).
Alguns sistemas de arquivos também podem compactar arquivos curtos para ocupar menos espaço compartilhando blocos (veja, por exemplo, empacotamento de cauda ) e outros como btrfs copiam na gravação , portanto, o relacionamento entre um arquivo, seu comprimento lógico e quanto espaço ele ocupa um disco é complexo.
(1) Na verdade, não é um buraco , está no final ... mas ainda assim, funciona até o final do exemplo.
ls -lé apenas um formato longo. ls -lsé usado para exibir o tamanho do bloco.
Como podemos ver, o tamanho do arquivo está listado como 2B. No entanto, se você precisar verificar o tamanho do bloco, execute o comando abaixo.
O 4 acima mostra o tamanho do bloco usado. Também pode verificar o mesmo usando o statcomando.
Agora, surge a pergunta sobre por que ls -lslista o tamanho do bloco como 4 enquanto statexibe o tamanho do bloco como 8. O motivo desse comportamento está claramente explicado na resposta aqui .
Muitos discos têm um tamanho de setor de 512 bytes, o que significa que qualquer leitura ou gravação no disco transfere um setor inteiro de 512 bytes por vez. É bastante natural projetar sistemas de arquivos onde um setor não é dividido entre arquivos (isso complicaria o design e prejudicaria o desempenho); portanto, os sistemas de arquivos tendem a usar blocos de 512 bytes para arquivos. Portanto, utilitários tradicionais como lse duindicam tamanhos em unidades de blocos de 512 bytes.