Incompatibilidade de tamanho de arquivo

Question

Qual é o motivo por trás da diferença nos tamanhos de arquivo relatados?

[root@localhost]# ls -lah sendlog
-rw-rw-r-- 1 mail mail 1.3T Aug 15 17:30 sendlog

[root@localhost]# du -m sendlog
24M  sendlog

Isso veio à nossa atenção quando o backup de um servidor continuava com problemas de cota, portanto, não era apenas "ls" que estava vendo esse tamanho errado.

Termos como "arquivos esparsos" e "atribuição de bloco" vêm à mente, mas não sei por que isso aconteceria ou a verdadeira razão por trás disso. Obviamente, há uma diferença nas maneiras como os dois comandos verificam o tamanho, estou certo sempre confiando em du?

FYI, isso deve ser um arquivo de log de mensagens padrão.

    

Answer 1

A diferença entre os valores é a seguinte.

Do manual de stat (2)

struct stat {
    // snip
    off_t     st_size;    /* total size, in bytes */
    // snip
    blkcnt_t  st_blocks;  /* number of blocks allocated */
    // snip
};

The st_blocks field indicates the number of blocks allocated to the file, 512-byte units. (This may be smaller than st_size/512, for example, when the file has holes.)

O tamanho relatado por ls é st_size , o tamanho relatado por du é st_blocks * 512

O valor relatado por du é o número de bytes usados pelo arquivo no sistema de arquivos / disco, e o valor relatado por ls é o tamanho / tamanho real do arquivo quando você interage com ele. (Além de operar com uso em disco, du também conta apenas arquivos hardlilnked uma vez)

Qual valor é o "correto" depende do contexto. Se você está após o uso do disco du está correto, se você está se perguntando quantos bytes estão no arquivo, ls / st_size está correto.

Além disso, você pode usar várias opções get ie du (--apparent-size) para usar o tamanho reportado por st_size ou você pode obter ls (-s) para relatar o número de blocos usados.

Sua suposição de que seu arquivo de registro é um arquivo esparso parece plausível, no entanto, a razão pela qual eu não sei.

    

Answer 2

Assim como Kjetil explicou, você tem um arquivo esparso. Blocos de dados em branco dentro do arquivo não são alocados no disco até que você realmente grave nesses blocos. Como isso aconteceu em um arquivo de log é um mistério. Você precisa verificar seus logs de auditoria desde a última vez que o sendlog teve um tamanho correto até o momento em que tinha esse buraco enorme. Talvez a resposta esteja no próprio arquivo de log.

Talvez alguém tenha intencionalmente causado estragos em seu sistema. Ou foi algum erro de software.

Você pode criar seu próprio arquivo de tamanho de terabyte facilmente com:

dd if=/dev/zero of='OMG_Thats_a_1_terabyte_file!!.dat' seek=1T bs=1 count=1

Esse arquivo alocará apenas alguns kilobytes de espaço em disco em qualquer versão atual do Linux com um sistema de arquivos com suporte para arquivos esparsos.

Sua solução de backup precisa de uma substituição. Qualquer sistema de backup sério hoje em dia lida com arquivos esparsos com eficiência. Mesmo a solução mais simples usando o GNU tar suporta (opção -S ou --sparse).

    

Answer 3

Talvez o seu du não suporte números tão grandes?

    

Answer 4

Seu sistema de arquivos pode estar corrompido (ou o disco tem alguns problemas físicos). Você deve fazer o fsck ASAP (na partição não montada) e ver o que acontece com esses números depois.