Como um diretório não vazio pode ter tamanho 0?

Question

Eu tenho um diretório com 18 arquivos, mas stat e outras ferramentas relatam seu tamanho como 0 . Como isso é possível?

$ \stat $PWD
  File: '/home/users/gholl/checkouts_local/FCDR_HIRS/FCDR_HIRS/analysis'
  Size: 0               Blocks: 0          IO Block: 524288 directory
Device: 14h/20d Inode: 62487444829821592  Links: 1
Access: (0755/drwxr-xr-x)  Uid: (35063/   gholl)   Gid: (26030/   users)
Access: 2018-04-09 11:38:43.574427000 +0100
Modify: 2018-04-09 11:38:43.574427000 +0100
Change: 2018-04-09 11:38:43.575000000 +0100
~/checkouts_local/FCDR_HIRS/FCDR_HIRS/analysis$ \ls -1 | wc -l
18

$ mount | grep homeusers
172.26.72.131:/homeusers on /home/users type nfs (rw,tcp,hard,intr,timeo=50,addr=172.26.72.131)

A máquina é uma versão 6.9 (Santiago) do Servidor Red Hat Enterprise Linux. De acordo com df -T , o tipo de sistema de arquivos é nfs :

$ df -hT .
Filesystem    Type    Size  Used Avail Use% Mounted on
172.26.72.131:/homeusers
               nfs    200T  3.5T  197T   2% /home/users

Eu pensei que o tamanho de um diretório estava relacionado ao número de arquivos nele, pois ele armazenava seus metadados. Então, como pode ser zero para um diretório não vazio?

NB: Eu não tenho acesso ao servidor e não tenho poderes de superusuário, então não posso investigar o que acontece no servidor.

    

Answer 1

Depende do sistema de arquivos subjacente no servidor NFS. Em última análise, isso se resume a um pouco estranho e pouco conhecido de semântica POSIX, ou seja, que o campo st_blocks retornado por stat() não inclui blocos alocados como metadados , somente blocos alocados como < em> data .

Essa distinção se originou quando os sistemas de arquivos padrão nos sistemas UNIX usavam tabelas de inodes alocadas estaticamente, o que significava que havia uma quantidade fixa de espaço usada por cada objeto do sistema de arquivos para metadados (e, portanto, não fazia sentido se preocupar com isso. tamanho do arquivo, pois não contribuiu para o uso total do espaço do arquivo (porque a tabela de inodes foi alocada estaticamente, esse espaço já estava reservado). Nesses sistemas de arquivos, as entradas de diretório não eram armazenadas como metadados, mas como blocos regularmente alocados no arquivo principal. parte do sistema de arquivos (IOW, entradas de diretório são tratadas como conteúdo de arquivo, não como metadados) É por isso que a maioria dos diretórios em sistemas UNIX mais antigos são múltiplos de 4kB, já que é o tamanho de bloco para a maioria dos sistemas de arquivos UNIX. também por que stat() e ferramentas que o usam relatam tamanhos de arquivo sem contabilizar metadados.

Em muitos sistemas de arquivos mais novos, no entanto, as coisas são bem diferentes. O espaço para metadados é alocado dinamicamente em vez de ser uma tabela estática de entradas de tamanho fixo, e entradas de diretório são tratadas como metadados. Como resultado, dependendo do sistema e sistema de arquivos exatos, os diretórios podem mostrar como zero tamanho aparente, ou podem mostrar uso de disco zero (como relatado por stat ou du ) mas um pequeno tamanho aparente sub-kB conforme relatado por %código%. O BTRFS é um bom exemplo de um sistema de arquivos que se enquadra na segunda categoria, o tamanho aparente de um diretório é uma função de quantas entradas existem e por quanto tempo seus nomes estão, enquanto o tamanho reportado em disco é recuperado de ls é sempre zero.