私はいつも/ ...システムコールによって返されたフィールドがst_blocks512バイト単位で表されるファイルのディスク使用量を取得するために使用されると仮定します。stat()lstat()du
調査するPOSIX仕様今、POSIXはこれについていかなる保証もしないことがわかりました。perl独自のstat()機能に関する文書化また、このような仮定をしないように警告します。
st_blksizeそれにもかかわらず、POSIXが示すように、このブロックサイズは返されたフィールドとは関係がないため、stat()他の場所で見つける必要があります。
GNUduまたはGNUfindソースコードを確認すると、HP / UXが1024バイト単位を使用しているという証拠が表示されます。 GNUは常に複数の512バイト単位を提供するように出力をfind調整します-printf %bが、これが混乱の原因となる可能性があります。
st_blocks512バイト単位で表現されていない他のUnixシリーズシステムはまだ使用されていますか？ POSIXで提案されているように、ファイルシステムによって異なりますか？ HP / UX NFS共有をマウントすると問題が解決するようです。
答え1
st_blksizeこれを使用する単位に関係なく、「最適I / Oサイズ」と呼びますst_blocks。もちろん、最適なI / Oサイズはファイルシステムによって異なります。これはfast filesystem1981/1982年のBerlekey開発の結果です。以前は、利用可能なファイルシステムの中で最適なブロックサイズはありませんでした。
st_blocks単位で表現すると、DEV_BSIZE実際にはHP-UXでは1024です。DEV_BSIZEプラットフォーム固有の定数です。後でFFS名前が変更されたとき、UFS間接ブロックとは異なる動作を持ち、この新しいstat()フィールドを必要とする2番目のファイルシステムがBSD UNIXに登場しました。以前は、duファイルシステムの間接ブロックのアルゴリズムだけを知っていました。
dfHP-UX NFSファイルサーバーや他のNFSクライアントを実行している場合、HPは過去15年間に問題を解決し、最新バージョンのHPにアクセスできない場合を除き、HP-UX NFSサーバーからエラーレポートを受け取ります。 - UX。私が知っている限り、他のUNIXには同様のNFS関連のバグはありません。
注：NFSv3まで、NFSはブロックサイズを512と仮定し、HPはサーバー上のNFSレポートを変換する必要がありました。 NFSv4はこれらの暗黙的な仮定をしませんが、HP-UXはまだ間違った数を報告します。
私が知る限り、他のUNIXは1024に基づいていませんDEV_BSIZE。