18個のファイルがあるディレクトリがあり、stat他のツールではそのサイズを0。
$ \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)
システムはRed Hat Enterprise Linux Serverバージョン6.9（San Diego）です。によると、df -Tファイルシステムの種類は次のとおりですnfs。
$ df -hT .
Filesystem Type Size Used Avail Use% Mounted on
172.26.72.131:/homeusers
nfs 200T 3.5T 197T 2% /home/users
ディレクトリのサイズはファイルのメタデータを格納するので、その中にあるファイル数と関連があると思います。それでは、空でないディレクトリに対してどのようにゼロになることができますか？
注：サーバーへのアクセス権やスーパーユーザー権限がないため、サーバー側で何が起こっているのかを調べることはできません。
ベストアンサー1
これは、NFS サーバーの基本ファイルシステムによって異なります。最終的に、これはPOSIXの意味のやや奇妙で未知のビットに帰結します。つまり、st_blocks返されるフィールドには、stat()次のように割り当てられたブロックは含まれません。メタデータ、次のように割り当てられたブロックのみデータ。
これらの違いは、UNIXシステムの標準ファイルシステムが静的に割り当てられたinodeテーブルを使用するという事実に由来します。つまり、各ファイルシステムオブジェクトはメタデータに固定量のスペースを使用します。したがって、ファイルサイズからそのスペースを計算することを心配する必要はありません。これは、ファイルの全体的なスペース使用量に貢献しないためです（inodeテーブルが静的に割り当てられているため、このスペースはすでに予約されています）。これらのファイルシステムでは、ディレクトリエントリはメタデータとして保存されず、代わりに主要部分に定期的に保存されます。割り当てられたブロックファイルシステム（IOW、ディレクトリエントリはメタデータではなくファイルの内容として扱われます）。これは、以前のUNIXシステムのほとんどのディレクトリサイズが4kBの倍数である理由です。これは、ほとんどのUNIXファイルシステムサイズのブロックサイズであるためです。これが、stat()それを使用するツールがメタデータを考慮せずにファイルサイズを報告する理由です。
しかし、多くの最新のファイルシステムでは、状況はかなり異なります。メタデータスペースは、固定サイズエントリの静的テーブルではなく動的に割り当てられ、ディレクトリエントリはメタデータとして扱われます。したがって、特定のシステムとファイルシステムによっては、ディレクトリの見かけのサイズはゼロとして表示され、ディスク使用量は0（または報告されているようにstat）duですが、報告されているように見かけのサイズは小さいように見える場合がありますls。 BTRFSは、2番目のカテゴリに属するファイルシステムの良い例です。ディレクトリの見かけのサイズは、ディレクトリ内のエントリの数とその名前の長さによって異なります。報告されるディスクサイズは次のとおりですstat()。常に0です。