为什么ls -l输出的大小与ls -s不同？

38

我不知道为什么会得到以下结果：

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 1in 使用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。

我尝试搜索网络，但唯一能找到的似乎是这样的：

某些文件中有“孔”，因此ls -s（...）列出的使用情况小于ls -l。列出的文件大小。”

（请注意，在我的结果中，情况恰恰相反：ls -s返回的大小大于ls -l，而不是较小。）

同时，此页显示

没有优雅的方法可以检测Unix文件漏洞。

那么，我该如何处理这种差异？以下哪个值可以被认为是正确的？这可能是其中的错误ls吗？

command-line ls

— 瓦尔迪罗斯
source

47

简短答案：

ls -l 给出文件的大小（=文件包含的数据量）
ls -s --block-size 1 给出文件系统上文件的大小

让我们创建两个文件：

甲稀疏文件的128个字节长度（A稀疏文件是包含空块的文件时，看到的稀疏文件）：

# 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

因此，如您在十六进制表示中所见，两个文件具有相同的数据量，尽管内容差别很大。

现在，让我们看一下目录：

# 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个字节！

该值取决于基础文件系统如何处理文件（块大小，稀疏文件功能等）。

在第六列是文件的大小，如果你会读它-它是该文件包含的数据量，它的这两个文件的128个字节！

— 菲波
source

1

据推测，即使是一个空文件或充满空值的文件也会占用文件分配表中某处的空间吗？为什么不ls -s计算呢？

— Flimm 2013年

2

有关文件的元数据存储在inode中。每个文件系统可以使用的inode数量有限。要查看文件系统有多少个可用的inode以及它们的大小：sudo tune2fs -l /dev/sdaX|grep Inode，或df -i所有分区。

— phoibos

1

我只是找到了一种有趣的，非人工的方式来验证这一点：torrent .part文件似乎是带有孔的文件的很好示例：ls -lsh ~/Downloads/torrents例如，给我92K -rw-r--r-- 1 waldir waldir 350M Sep 15 2012 video.avi.part。也就是说，92K，通过-s选项返回，是文件需要，文件系统的角度来看，和350M的实际空间，由-l选项返回，是全尺寸的文件将有如果它被完全下载（即如果所有字节（从头到尾）均为非零）。请参阅lists.freebsd.org/pipermail/freebsd-questions/2012年

— 6

14

ls -s告诉您文件的分配大小，始终是分配单位的倍数。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

— 贡特伯特
source