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

Question

我有一个非常高密度的容器虚拟化环境，所以我试图让每个容器都非常小。“非常小”意味着在基本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

等等哦，shi~

我们总共有 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 月，所以在第一个 KB 之后的某个地方。看起来很合理，ext4 跳过了前 1024 个字节，用于像 VBR 等奇怪的东西。

2. 这是日记！

不它不是。如果 df 输出，则日志从可用空间中获取空间。

3. 哦，我们有 dump2fs 并且可以检查那里的大小！

...很多greps ...

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 说）

Answer 1

尝试这个： 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“成本”可用空间（您在df- 12K 中看到的 1550 个 1K-Blocks/2% 中的大部分用于“lost+found”文件夹）
• has_journal“成本”可用空间（在您的情况下为 4096 1K 块）

我们102348退出了102400，另外 52 个块无法使用（如果我们删除了“lost+found”文件夹）。因此，我们深入研究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引导扇区之类的开头跳过的字节。

Answer 2

简短的回答：

并非块设备上的所有空间都成为您数据的可用空间：文件系统内部需要一些原始空间，即幕后簿记。

该簿记包括超级块、块组描述符、块和 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 KB 的原始存储空间块已无法用于实际数据存储。

这些积木去了哪里？在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 被主超级块占用。
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（文件系统的大小）减去 5120（保留块数）减去 5646（使用的块，其中 4096 个来自日志（也是 dumpe2fs 输出的一部分））
= 88384

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