LVM 占用了我的磁盘空间还是 df 撒谎了？

Question 1

让我们做一些研究。我以前就注意到了这种差异，但从未详细检查过将损失归因于什么。看看我的场景进行比较：fdisk 显示以下分区：

/dev/sda3       35657728 1000214527 964556800  460G 83 Linux

由于我的文件系统位于 luks 容器中，因此会有一些损失，但这应该只有几个 MiB。 df 显示：

Filesystem      Size  Used Avail Use% Mounted on
/dev/dm-1       453G  373G   58G  87% /

（luks容器也是/dev/sda3与/dev/dm-1不匹配的原因，但它们确实是同一个设备，中间有加密，没有LVM。这也说明LVM不对你的损失负责，我有他们也是。）

现在让我们向文件系统本身询问这个问题。调用tune2fs -l，它会输出许多有关 ext 系列文件系统的有趣信息，我们得到：

root@altair ~ › tune2fs -l /dev/dm-1
tune2fs 1.42.12 (29-Aug-2014)
Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          0de04278-5eb0-44b1-9258-e4d7cd978768
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              30146560
Block count:              120569088
Reserved block count:     6028454
Free blocks:              23349192
Free inodes:              28532579
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      995
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Wed Oct 14 09:27:52 2015
Last mount time:          Sun Mar 13 12:25:50 2016
Last write time:          Sun Mar 13 12:25:48 2016
Mount count:              23
Maximum mount count:      -1
Last checked:             Wed Oct 14 09:27:52 2015
Check interval:           0 (<none>)
Lifetime writes:          1426 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       26747912
Default directory hash:   half_md4
Directory Hash Seed:      4723240b-9056-4f5f-8de2-d8536e35d183
Journal backup:           inode blocks

扫了一眼，第一个映入眼帘的应该是Reserved blocks。将其与Block size（也来自输出）相乘，我们得到 dfUsed+Avail 和 Size 之间的差：

453GiB - (373GiB+58GiB) = 22 GiB
6028454*4096 Bytes = 24692547584 Bytes ~= 23 GiB

足够接近，特别是考虑到 df 轮次（使用不带 -h 的 df 并重复计算，仅留下 16 MiB 的Used+Avail 和 Size 之间的差异无法解释）。保留块的保留对象也写在tune2fs 输出中。是根。这是一个安全网，可确保非 root 用户无法通过填充磁盘来使系统完全无法使用，并且保持百分之几的磁盘空间未使用也有助于防止碎片。

现在看看 df 报告的大小与分区大小之间的差异。这可以通过查看索引节点来解释。 ext4 预分配 inode，因此该空间无法用于文件数据。Inode count将乘以，Inode size即可得到：

30146560*256 Bytes = 7717519360 Bytes ~= 7 GiB
453 GiB + 7 GiB = 460 GiB

索引节点基本上是目录条目。让我们向 mkfs.ext4 询问详细信息（来自 man mkfs.ext4）：

-我bytes-per-inode

指定字节/索引节点比率。 mke2fs 为 bytes-per-inode 磁盘上的每个字节空间创建一个 inode。该比率越大 bytes-per-inode ，创建的 inode 就越少。该值通常不应小于文件系统的块大小，因为在这种情况下，将创建比可以使用的更多的 inode。请注意，文件系统创建后无法更改该比率，因此请谨慎确定该参数的正确值。请注意，调整文件系统大小会更改 inode 数量以维持此比率。

有不同的预设可用于不同的场景。在具有大量 Linux 发行版映像的文件服务器上，传递 eg-T largefile甚至-T largefile4.含义在这些示例和我的系统中-T定义：/etc/mke2fs.conf

largefile = {
    inode_ratio = 1048576
}
largefile4 = {
    inode_ratio = 4194304
}

所以对于-T largefile4，的数量远小于默认值（我的默认比率是 16384 /etc/mke2fs.conf）。这意味着为目录条目保留的空间更少，为数据保留的空间更多。当索引节点用完时，您将无法创建新文件。增加现有文件系统中的 inode 数量似乎不可能。因此，默认的 inode 数量是相当保守地选择的，以确保普通用户不会过早地用完 inode。

我只是在查看我的数字时发现了这一点，请告诉我它是否（不）适合您☺。

Answer