web-dev-qa-db-ja.com

ls -lがls -sと異なるサイズを出力するのはなぜですか？

次の結果が得られる理由がわかりません。

ls -lは、特定のファイル（HISTORY）のサイズが「581944」であることを示しています。

$ ls -l HISTORY 
-rw-rw-r-- 1 waldyrious waldyrious 581944 Feb 22 10:59 HISTORY

ls -sは「572」であると言います：

$ ls -s HISTORY
572 HISTORY

当然、値に同等のスケールを使用する必要があります。したがって、最初に--block-size 1でls -lを使用すると、以前と同じ結果が得られることを確認します。

$ ls -l --block-size 1 HISTORY 
-rw-rw-r-- 1 waldyrious waldyrious 581944 Feb 22 10:59 HISTORY

次に、同じスケールで値を取得するためにls -sに対して同じことを行います。

$ ls -s --block-size 1 HISTORY 
585728 HISTORY

異なる結果！ 581944≠585728。

-kを使用して、逆の方法で比較可能な値を生成しようとしましたが、次のようになります。

$ ls -lk HISTORY 
-rw-rw-r-- 1 waldyrious waldyrious 569 Feb 22 10:59 HISTORY
$ ls -sk HISTORY 
572 HISTORY

繰り返しますが、異なる結果、569≠572。

--siを指定して、両方のオプションが同じスケールを使用していることを確認しましたが、役に立ちませんでした。

$ ls -lk --si HISTORY 
-rw-rw-r-- 1 waldyrious waldyrious 582k Feb 22 10:59 HISTORY
$ ls -sk --si HISTORY 
586k HISTORY

...再び、異なる値：582k≠586k。

ウェブを検索してみましたが、関連性があると思われる唯一のことは、 this ：

一部のファイルには「穴」があるため、ls -s（...）でリストされる使用量は、ls -lでリストされるファイルサイズよりも小さくなります。

（私の結果では反対のことが起こることに注意してください：ls -sはls -lよりも大きいサイズを返しますが、小さくはありません。）

一方、 このページ は

unixファイルホールを検出するエレガントな方法はありません。

だから、この矛盾にどうやって対処できますか？これらの値のどれが正しいと考えることができますか？これはおそらくlsのバグでしょうか？

command-linels
36
waldyrious

短い答え：

  • ls -lはファイルのサイズを示します（=ファイルに含まれるデータの量）
  • ls -s --block-size 1は、ファイルシステム上のファイルのサイズを示します

2つのファイルを作成しましょう：

128バイト長のスパースファイル（スパースファイルは空のブロックを含むファイルです。 スパースファイル を参照）：

# truncate -s 128 f_zeroes.img
# hexdump -vC f_zeroes.img 
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080

サイズが128バイトのランダムデータを含む別のファイル：

# dd if=/dev/urandom of=f_random.img bs=1 count=128
# hexdump -vC f_random.img 
00000000  bc 82 9c 40 04 e3 0c 23  e6 76 79 2f 95 d4 0e 45  |...@...#.vy/...E|
00000010  19 c6 53 fc 65 83 f8 58  0a f7 0e 8f d6 d6 f8 b5  |..S.e..X........|
00000020  6c cf 1b 60 cb ef 06 c6  d0 99 c6 16 3f d3 95 02  |l..`........?...|
00000030  85 1e b7 80 27 93 27 92  d0 52 e8 72 54 25 4d 90  |....'.'..R.rT%M.|
00000040  11 59 a2 d9 0f 79 aa 23  2d 44 3d dd 8d 17 d9 36  |.Y...y.#-D=....6|
00000050  f5 ae 07 a8 c1 b4 cb e1  49 9e bc 62 1b 4f 17 53  |........I..b.O.S|
00000060  95 13 5a 1c 2a 7e 55 b9  69 a5 50 06 98 e7 71 83  |..Z.*~U.i.P...q.|
00000070  5a d0 82 ee 0b b3 91 82  ca 1d d0 ec 24 43 10 5d  |Z...........$C.]|
00000080

そのため、16進表記でわかるように、両方のファイルには同じ量のデータがありますが、内容はまったく異なります。

次に、ディレクトリを見てみましょう：

# ls -ls --block-size 1 f_*
1024 -rw-r--r-- 1 user user 128 Mar 18 15:34 f_random.img
   0 -rw-r--r-- 1 user user 128 Mar 18 15:32 f_zeroes.img
   ^                         ^
   |                         |
Amount which the           Actual file size
files takes on the fs

最初の値は-s --block-size 1オプションで指定されます。これは、ファイルシステム上のファイルが使用する容量です。

ご覧のとおり、ファイルシステム（この場合はext3）が十分にスマートであるため、スパースファイルのスペースはゼロであり、ゼロしか含まれていないことがわかります。また、ランダムデータを含むファイルは、ディスク上で1024バイトを占有します！

値は、基礎となるファイルシステムがファイルを処理する方法（ブロックサイズ、スパースファイル機能など）によって異なります。

6番目の列は、読み取る場合のファイルのサイズです。ファイルに含まれるデータ量で、128バイトです両方のファイルに！

44
phoibos

ls -sは、ファイルのallocatedサイズを示します。常に割り当て単位の倍数です。 ls -lは実際のサイズを示します。テストする簡単な方法：

$ echo 1 > sizeTest
$ ls -l --block-size 1 sizeTest 
-rw-rw-r-- 1 g g 2 Mär 18 15:18 sizeTest
$ ls -s --block-size 1 sizeTest 
4096 sizeTest
14
guntbert