Início / unix / Perguntas / 436565
Accepted
gerrit
Asked: 2018-04-10 08:15:37 +0800 CST

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

  • 772

Eu tenho um diretório com 18 arquivos, mas statoutras 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 é um Red Hat Enterprise Linux Server versão 6.9 (Santiago). 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 armazenava seus metadados. Então, como pode ser zero para um diretório não vazio?

NB: Não tenho acesso ao servidor e não tenho poderes de superusuário, portanto não posso investigar o que acontece no lado do servidor.

rhel directory

1 respostas

  1. Best Answer

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

    Essa distinção se originou quando os sistemas de arquivos padrão em sistemas UNIX usavam tabelas inode alocadas estaticamente, o que significava que havia uma quantidade fixa de espaço usado por cada objeto do sistema de arquivos para metadados (e, portanto, não fazia sentido se preocupar em contar isso no tamanho do arquivo, pois não contribuiu para o uso total do espaço do arquivo (porque a tabela inode foi alocada estaticamente, esse espaço já estava reservado) Nesses sistemas de arquivos, as entradas do diretório não eram armazenadas como metadados, mas como blocos alocados regularmente na parte principal do sistema de arquivos (IOW, as 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 tem um tamanho múltiplo de 4kB, já que esse é o tamanho do bloco para a maioria dos sistemas de arquivos UNIX, e também é por issostat()e as ferramentas que o usam relatam tamanhos de arquivo sem contabilizar metadados.

    No entanto, em muitos sistemas de arquivos mais novos, 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 as entradas de diretório são tratadas como metadados. Como resultado, dependendo do sistema exato e do sistema de arquivos, os diretórios podem mostrar como tendo tamanho aparente zero ou podem mostrar uso de disco zero (conforme relatado por statou du), mas um tamanho aparente sub-kB pequeno conforme relatado por ls. 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 estão nele e quanto tempo seus nomes são, enquanto o tamanho do disco relatado que você obtém stat()é sempre zero.

    • 3

relate perguntas