为什么我的精确的100 MiB分区（1 KiB块大小）没有相应的可用块/空间？

33

我有一个带有容器的非常高密度的虚拟化环境，因此我试图将每个容器做得很小。“非常小”表示在基本Ubuntu 14.04（Trusty Tahr）上为87 MB，而不会破坏程序包管理器的兼容性。

因此，我将LVM用作容器的后备存储，最近我发现了非常奇怪的数字。他们来了。

让我们创建一个100 MiB（是的，2的幂）逻辑卷。

sudo lvcreate -L100M -n test1 /dev/purgatory

我想检查一下尺寸，所以发出 sudo lvs --units k

test1             purgatory  -wi-a----  102400.00k

太好了，这确实是100 MiB。

现在让我们制作一个ext4文件系统。当然，我们还记得-m 0参数，它可以防止空间浪费。

sudo mkfs.ext4 -m 0 /dev/purgatory/test1

mke2fs 1.42.9 (4-Feb-2014)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
25688 inodes, 102400 blocks
0 blocks (0.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
13 block groups
8192 blocks per group, 8192 fragments per group
1976 inodes per group
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345, 73729

Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

甜而干净。注意块的大小-我们的逻辑体积很小，因此mkfs.ext4决定制作1 KiB大小的块，而不是通常的4 KiB。

现在我们将其安装。

sudo mount /dev/purgatory/test1 /mnt/test1

让我们在df不带参数的情况下进行调用（我们希望看到1个KiB块）

/dev/mapper/purgatory-test1     95054    1550     91456   2% /mnt/test1

等等，哦〜

我们总共有95054个方块。但是设备本身具有102400个1 KiB的块。我们只有92.8％的存储空间。老兄，我的街区在哪里？

让我们在一个真正的块设备上查看它。A有一个16 GiB虚拟磁盘，其16777216个1K块，但在df输出中只有15396784个块。91.7％，这是什么？

现在进行调查（破坏者：无结果）

  1. 文件系统可能不在设备的开头开始。这很奇怪，但是可能。幸运的是，ext4有魔术字节，让我们检查它们的存在。

    须藤hexdump -C / dev / purgatory / test1 | grep“ 53 ef”

这显示了超级块：

00000430  a9 10 e7 54 01 00 ff ff  53 ef 01 00 01 00 00 00  |...T....S.......|

十六进制430 = 1072年12月，因此在第一个千字节之后。看起来很合理，ext4会跳过前1024个字节，以防止出现VBR等异常情况。

  1. 这是日记！

不它不是。如果df输出，则日志从“可用”中占用空间。

  1. 哦，我们有dump2fs，可以在那里查看大小！

...很多of ...

sudo dumpe2fs /dev/purgatory/test1 | grep "Free blocks"

哎哟。

Free blocks:              93504
  Free blocks: 3510-8192
  Free blocks: 8451-16384
  Free blocks: 16385-24576
  Free blocks: 24835-32768
  Free blocks: 32769-40960
  Free blocks: 41219-49152
  Free blocks: 53249-57344
  Free blocks: 57603-65536
  Free blocks: 65537-73728
  Free blocks: 73987-81920
  Free blocks: 81921-90112
  Free blocks: 90113-98304
  Free blocks: 98305-102399

我们还有另一个号码。93504个免费块。

问题是：怎么回事？

  • 块设备：102400k（lvs说）
  • 文件系统大小：95054k（df说）
  • 免费块：93504k（dumpe2fs说）
  • 可用大小：91456k（df说）
ext4 
— 疯子
source
这就是为什么我仍然使用ext2小型分区的原因。
— frostschutz
@frostschutz ext2在这里看起来很合理
— 狂躁症

Answers:

32

尝试这个： mkfs.ext4 -N 104 -m0 -O ^has_journal,^resize_inode /dev/purgatory/test1

我认为这确实可以让您了解“发生了什么”。

-N 104 （设置文件系统应具有的iNode数）

  • 每个iNode都会“消耗” 可用空间（128字节）

-m 0（无保留块）
-O ^has_journal,^resize_inode（停用功能has_journal和resize_inode

  • resize_inode“花费” 可用空间（您看到的大部分1550 1K块/ 2％df-12K用于“丢失+找到”文件夹）
  • has_journal“花费” 可用空间（您的情况为4096个1K块）

我们102348退出102400，另外52个块不可用（如果我们已删除“丢失+找到”文件夹）。因此，我们潜入dumpe2fs：

Group 0: (Blocks 1-8192) [ITABLE_ZEROED]
  Checksum 0x5ee2, unused inodes 65533
  Primary superblock at 1, Group descriptors at 2-2
  Block bitmap at 3 (+2), Inode bitmap at 19 (+18)
  Inode table at 35-35 (+34)
  8150 free blocks, 0 free inodes, 1 directories, 65533 unused inodes
  Free blocks: 17-18, 32-34, 48-8192
  Free inodes: 
Group 1: (Blocks 8193-16384) [BLOCK_UNINIT, ITABLE_ZEROED]
  Checksum 0x56cf, unused inodes 5
  Backup superblock at 8193, Group descriptors at 8194-8194
  Block bitmap at 4 (+4294959107), Inode bitmap at 20 (+4294959123)
  Inode table at 36-36 (+4294959139)
  8190 free blocks, 6 free inodes, 0 directories, 5 unused inodes
  Free blocks: 8193-16384
  Free inodes: 11-16
Group 2: (Blocks 16385-24576) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
  Checksum 0x51eb, unused inodes 8
  Block bitmap at 5 (+4294950916), Inode bitmap at 21 (+4294950932)
  Inode table at 37-37 (+4294950948)
  8192 free blocks, 8 free inodes, 0 directories, 8 unused inodes
  Free blocks: 16385-24576
  Free inodes: 17-24
Group 3: (Blocks 24577-32768) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
  Checksum 0x3de1, unused inodes 8
  Backup superblock at 24577, Group descriptors at 24578-24578
  Block bitmap at 6 (+4294942725), Inode bitmap at 22 (+4294942741)
  Inode table at 38-38 (+4294942757)
  8190 free blocks, 8 free inodes, 0 directories, 8 unused inodes
  Free blocks: 24577-32768
  Free inodes: 25-32
Group 4: (Blocks 32769-40960) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
  Checksum 0x79b9, unused inodes 8
  Block bitmap at 7 (+4294934534), Inode bitmap at 23 (+4294934550)
  Inode table at 39-39 (+4294934566)
  8192 free blocks, 8 free inodes, 0 directories, 8 unused inodes
  Free blocks: 32769-40960
  Free inodes: 33-40
Group 5: (Blocks 40961-49152) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
  Checksum 0x0059, unused inodes 8
  Backup superblock at 40961, Group descriptors at 40962-40962
  Block bitmap at 8 (+4294926343), Inode bitmap at 24 (+4294926359)
  Inode table at 40-40 (+4294926375)
  8190 free blocks, 8 free inodes, 0 directories, 8 unused inodes
  Free blocks: 40961-49152
  Free inodes: 41-48
Group 6: (Blocks 49153-57344) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
  Checksum 0x3000, unused inodes 8
  Block bitmap at 9 (+4294918152), Inode bitmap at 25 (+4294918168)
  Inode table at 41-41 (+4294918184)
  8192 free blocks, 8 free inodes, 0 directories, 8 unused inodes
  Free blocks: 49153-57344
  Free inodes: 49-56
Group 7: (Blocks 57345-65536) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
  Checksum 0x5c0a, unused inodes 8
  Backup superblock at 57345, Group descriptors at 57346-57346
  Block bitmap at 10 (+4294909961), Inode bitmap at 26 (+4294909977)
  Inode table at 42-42 (+4294909993)
  8190 free blocks, 8 free inodes, 0 directories, 8 unused inodes
  Free blocks: 57345-65536
  Free inodes: 57-64
Group 8: (Blocks 65537-73728) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
  Checksum 0xf050, unused inodes 8
  Block bitmap at 11 (+4294901770), Inode bitmap at 27 (+4294901786)
  Inode table at 43-43 (+4294901802)
  8192 free blocks, 8 free inodes, 0 directories, 8 unused inodes
  Free blocks: 65537-73728
  Free inodes: 65-72
Group 9: (Blocks 73729-81920) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
  Checksum 0x50fd, unused inodes 8
  Backup superblock at 73729, Group descriptors at 73730-73730
  Block bitmap at 12 (+4294893579), Inode bitmap at 28 (+4294893595)
  Inode table at 44-44 (+4294893611)
  8190 free blocks, 8 free inodes, 0 directories, 8 unused inodes
  Free blocks: 73729-81920
  Free inodes: 73-80
Group 10: (Blocks 81921-90112) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
  Checksum 0x60a4, unused inodes 8
  Block bitmap at 13 (+4294885388), Inode bitmap at 29 (+4294885404)
  Inode table at 45-45 (+4294885420)
  8192 free blocks, 8 free inodes, 0 directories, 8 unused inodes
  Free blocks: 81921-90112
  Free inodes: 81-88
Group 11: (Blocks 90113-98304) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
  Checksum 0x28de, unused inodes 8
  Block bitmap at 14 (+4294877197), Inode bitmap at 30 (+4294877213)
  Inode table at 46-46 (+4294877229)
  8192 free blocks, 8 free inodes, 0 directories, 8 unused inodes
  Free blocks: 90113-98304
  Free inodes: 89-96
Group 12: (Blocks 98305-102399) [INODE_UNINIT, ITABLE_ZEROED]
  Checksum 0x9223, unused inodes 8
  Block bitmap at 15 (+4294869006), Inode bitmap at 31 (+4294869022)
  Inode table at 47-47 (+4294869038)
  4095 free blocks, 8 free inodes, 0 directories, 8 unused inodes
  Free blocks: 98305-102399
  Free inodes: 97-104

并计算使用的块（用于备份超级块，组描述符，块位图，Inode位图和Inode表），或者我们grep计算：

LANG=C dumpe2fs /dev/mapper/vg_vms-test1 | grep ' at ' | grep -v ',' | wc -l

这给了我们具有单个块的行数（在我们的示例中），

LANG=C dumpe2fs /dev/mapper/vg_vms-test1 | grep ' at ' | grep ',' | wc -l

这给了我们具有两个块的行数（在我们的示例中）。

因此，在我们的示例中13，每行有一个块，每19行有两个块。

13+19*2

这给我们提供51了ext4本身正在使用的块。最后，仅剩一个街区了。块0，1024在启动扇区之类的内容的开头是跳过的字节。

— xx4h
source
而且如果journal只需要4096k，我就没有这个数字（95054-4096）！= 91456？
— 疯狂
这里的所有数字均以k为单位，因此总计为95054k-日记日志4096k！= 91456k。
— 疯狂
1
df在带有日记帐的fs上：95054k- df在没有jorunal 99150k的fs上-请勿混用“可用”和“可用”空间。
— xx4h 2015年
一些文件系统（例如xfs）会根据需要为inode动态分配空间。如果您好奇的话，可能要尝试使用xfs和btrfs。 mkfs.xfs -l size=512 -d agcount=1将使文件系统具有绝对最小日志（也称为日志）大小，但是写入性能可能会受到影响。我认为XFS代码支持在没有日志的情况下运行。可能是只读的，以支持外部日志设备损坏的情况。（而且，agcount=1这可能是写性能的另一个可怕的主意，尤其是并行。分配组头也可能很小。）
— Peter Cordes
好奇并尝试了XFS。如果Linux XFS的选项组合在一起，将使最小日志大小降至512块的绝对最小值，即IDK。 mkfs.xfs -d agcount=1在100MiB分区上制作的FS为95980kiB，已使用5196k，可用90784k。默认的agcount为4，默认的日志大小为1605个块（也是最小的）。因此，对于小型FS，XFS确实会使用您愿意指定的日志。
— 彼得·科德斯
19

简短的答案：

并不是块设备上的所有空间都变成了数据可用空间：文件系统内部需要一些原始空间，即幕后记账。

该簿记包括超级块，块组描述符，块和inode位图以及inode表。另外，在许多位置创建了用于备份/恢复目的的超级块的副本。可以在ext4.wiki.kernel.org上找到有关EXT4文件系统内部的详细信息。

由于EXT4是日志文件系统，因此也会占用一些空间。

另外，为将来扩展文件系统保留了一些空间。

长答案：

我已经在我的测试系统之一上重新创建了您的方案： 

lvcreate -L 100M -n test MyVG
mkfs.ext4 -b 1024 /dev/MyVG/test

然后甚至在挂载文件系统之前dumpe2fs显示：

Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              25688
Block count:              102400
Reserved block count:     5120
Free blocks:              93504
Free inodes:              25677
First block:              1
Block size:               1024
Fragment size:            1024
Reserved GDT blocks:      256
Blocks per group:         8192
Fragments per group:      8192
Inodes per group:         1976
Inode blocks per group:   247
Flex block group size:    16
Filesystem created:       Fri Feb 20 13:20:54 2015
Last mount time:          n/a
Last write time:          Fri Feb 20 13:20:55 2015
...
Journal size:             4096k  
...

安装后： 

df /tmp/test/
Filesystem              1K-blocks  Used Available Use% Mounted on
/dev/mapper/MyVG-test       99150  5646     88384   7% /tmp/test

那么df向我们展示了什么？从原始存储设备容量的102400块中，文件系统可以看到99150 1K块，这意味着3250 1千字节的原始存储空间已无法用于实际数据存储。

这些街区去了哪里？在dumpe2fs输出中向下滚动显示确切的位置：

Group 0: (Blocks 1-8192) [ITABLE_ZEROED]
  Checksum 0x0d67, unused inodes 1965
  Primary superblock at 1, Group descriptors at 2-2
  Reserved GDT blocks at 3-258
  Block bitmap at 259 (+258), Inode bitmap at 275 (+274)
  Inode table at 291-537 (+290)
  4683 free blocks, 1965 free inodes, 2 directories, 1965 unused inodes
  Free blocks: 3510-8192
  Free inodes: 12-1976

1 block （块0）跳过前1024个字节以允许安装x86引导扇区和其他异常。
1 block 被Primary超级块占用。
1 block 包含组描述符。
256 blocks被保留的组描述符表，以使文件系统的未来调整大小。 16 blocks 被分配给块位图。
16 blocks为inode位图分配。
246 blocks为inode表分配。

这已经占3250个缺失区块中的537个。ext4文件系统分为一系列块组，向下滚动进一步显示了原始存储容量对其他块组中文件系统内部的类似分配：

Group 1: (Blocks 8193-16384) [INODE_UNINIT, ITABLE_ZEROED]
  Checksum 0x0618, unused inodes 1976
  Backup superblock at 8193, Group descriptors at 8194-8194
  Reserved GDT blocks at 8195-8450
  Block bitmap at 260 (+4294959363), Inode bitmap at 276 (+4294959379)
  Inode table at 538-784 (+4294959641)
  7934 free blocks, 1976 free inodes, 0 directories, 1976 unused inodes
  Free blocks: 8451-16384
  Free inodes: 1977-3952
Group 2: (Blocks 16385-24576) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
  Checksum 0xcfd3, unused inodes 1976
  Block bitmap at 261 (+4294951172), Inode bitmap at 277 (+4294951188)
  Inode table at 785-1031 (+4294951696)
  8192 free blocks, 1976 free inodes, 0 directories, 1976 unused inodes
  Free blocks: 16385-24576
  Free inodes: 3953-5928 
Group ....

现在回到df输出：

df /tmp/test/
Filesystem              1K-blocks  Used Available Use% Mounted on
/dev/mapper/MyVG-test       99150  5646     88384   7% /tmp/test

在该新文件系统上已将7％的容量标记为正在使用的原因是：

99150（文件系统的大小）MINUS 5120（保留的块数）MINUS 5646（使用的块，其中4096个来自Journal（同样是dumpe2fs输出的一部分））
= 88384

dumpe2fs中的可用块数是文件系统的可用大小减去实际使用量（并且不考虑保留的块），因此99150-5646 = 93504。

— 鲁比恩
source
0

不能回答这个问题，但是我很好奇，所以我想其他人也会这样。由于我已经启动了liveCD，并且拥有硬盘驱动器，因此我可以不用担心拼写错误会损坏任何东西而烦恼，因此我继续进行了测试。

我在100MiB分区上使用Ubuntu 14.10随附了mkfs的所有FS进行了分区。（除了minix仅支持64MiB和bfs，这是我从未听说过的SCO。）

首先，我查看了df -k可用空间（使用默认的mkfs设置），然后dd编辑/dev/zero了每个FS上的文件，以确保可以将其填满。（即检查所声称的内容available space是否确实可用。）
for i in /media/ubuntu/small-*;do sudo dd if=/dev/zero of="$i/fill" bs=16k;done

* FS: empty `df -k` : non-zero `df -k` when full (false bottom)
* jfs:  101020k
* fat32:100808k  : 4
* ntfs:  99896k
* btrfs: 98276k  : 4428
* ext2:  92480k
* xfs:   90652k  : 20
* ext4:  86336k
* ext3:  88367k
* reiserfs(v3): 69552k

为什么btrfs有这么多无法使用的空间？也许是元数据？好吧：

$ for i in /media/ubuntu/small-*;do sudo touch "$i/touched";done
touch: cannot touch ‘/media/ubuntu/small-btrfs/touched’: No space left on device
touch: cannot touch ‘/media/ubuntu/small-reiser/touched’: No space left on device

两种基于树的文件系统都不能在任何地方打包空文件，而其他所有文件系统都可以。

或者只是看看您可以创建多大的文件：

$ ls -SdlG --block-size=1k /media/ubuntu/small-*/*
-rw-r--r-- 1 root   101020 Feb 21 11:55 /media/ubuntu/small-jfs/fill
-rw-r--r-- 1 ubuntu 100804 Feb 21 11:55 /media/ubuntu/small-fat/fill
-rw------- 1 ubuntu  99848 Feb 21 11:55 /media/ubuntu/small-ntfs/fill
-rw-r--r-- 1 root    97216 Feb 21 11:55 /media/ubuntu/small-ext2/fill
-rw-r--r-- 1 root    93705 Feb 21 11:27 /media/ubuntu/small-btrfs/foo
-rw-r--r-- 1 root    93120 Feb 21 11:55 /media/ubuntu/small-ext3/fill
-rw-r--r-- 1 root    91440 Feb 21 11:55 /media/ubuntu/small-ext/fill
-rw-r--r-- 1 root    90632 Feb 21 11:55 /media/ubuntu/small-xfs/fill
-rw-r--r-- 1 root    69480 Feb 21 11:55 /media/ubuntu/small-reiser/fill
drwx------ 2 root       12 Feb 21 11:33 /media/ubuntu/small-ext2/lost+found
drwx------ 2 root       12 Feb 21 11:43 /media/ubuntu/small-ext3/lost+found
drwx------ 2 root       12 Feb 21 11:29 /media/ubuntu/small-ext/lost+found

（我将ext4分区称为“ small-ext”，是因为我不打算花大价钱制作每个文件系统。所以这里ext = ext4。不是原始的pre-ext2 ext。）

并df -k再次删除它们后输出：

/dev/sdd6          95980    5328     90652   6% /media/ubuntu/small-xfs
/dev/sdd7          95054    1550     86336   2% /media/ubuntu/small-ext
/dev/sdd5         102400   93880    101020  96% /media/ubuntu/small-btrfs
/dev/sdd8         101168  101168         0 100% /media/ubuntu/small-jfs
/dev/sdd9          99150    1550     92480   2% /media/ubuntu/small-ext2
/dev/sdd10        102392   32840     69552  33% /media/ubuntu/small-reiser
/dev/sdd11        100808       1    100808   1% /media/ubuntu/small-fat
/dev/sdd12        102396    2548     99848   3% /media/ubuntu/small-ntfs
/dev/sdd13         95054    1567     88367   2% /media/ubuntu/small-ext3

（在我删除“ touched”之后，jfs也恢复到了1％的使用率。或者是有时间延迟，或者是花了另一笔写才能获得可用的大小来进行更新。）

无论如何，我认为这是出于我的好奇心。

— 彼得·科德斯
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.