単一のファイルが指定されていますh。プリミティブfindを使用して実行すると-ls、次の出力が得られます。
$ cat some_file
h
$ find . -ls
2750606 0 drwxr-xr-x 4 mbigras FOO\Domain Users 136 May 18 12:35 .
3067730 16 -rw-r--r-- 1 mbigras FOO\Domain Users 6148 May 18 12:33 ./.DS_Store
3067836 8 -rw-r--r-- 1 mbigras FOO\Domain Users 2 May 18 12:35 ./some_file
man find検索すると、ファイル-lsに関する次の情報が出力されていることがわかります。
inode 番号、512 バイト ブロック単位のサイズ、ファイル権限、ハード リンクの数、所有者、グループ、バイト単位のサイズ、最終変更時刻、およびパス名。
いくつか疑問に思うことがあります:
some_file1 バイトしかないのにh、なぜ「バイト単位のサイズ」が 2 なのでしょうか? 1 になるはずです。- 2 番目の数字が「512 バイト ブロック単位のサイズ」である場合、なぜ「バイト単位のサイズ」よりも大きいのでしょうか。0 か、少なくともそれより小さいと予想されます。
答え1
some_fileh改行が続き、合計2バイトになります。次のようにしてみてください。
hexdump -C some_file
ファイルの内容をバイトごとに表示します。
1 から 512 バイトまでのファイルは、それがディスク上の最小割り当てサイズである場合、1 つの 512 バイト ブロックを占めます。同様に、513 バイトのファイルは 2 つの 512 バイト ブロックを占めます。ブロック数は最も近い整数に切り捨てられません。
答え2
なぜ 512 バイトを使用するのか、その理由を見てみましょう。たとえば、ファイル サイズが 513 バイトの場合、このファイルを保存するには、ハード ディスクに 512 バイトのブロックが 2 つ必要になります。513 番目のバイトを節約するには、512 バイトを含む完全なハード ディスク ブロックを割り当てる必要があります。つまり、内部の断片化により 511 バイトが無駄になります。したがって、この内部の断片化を減らすには、ブロックのサイズをできるだけ小さく保つことが常に望ましいです。実験により、512 バイトが最適なサイズであることがわかりました。サイズを小さくすると、ファイルにアクセスするために多くのブロックにアクセスする必要があり、時間がかかります。したがって、最適化するには、効率を高め、メモリの無駄を減らすには、512 バイトがより良いサイズであることが実験的にわかりました。