LVM съедает мое дисковое пространство или df лжет?

Давайте проведем небольшое исследование. Я и раньше замечал эту разницу, но никогда не проверял подробно, на что можно списать потери. Посмотрите на мой сценарий для сравнения: 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-family, мы получаем:

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

Просматривая ее, первое, что бросается в глаза, это Зарезервированные блоки. Умножив это на Размер блока (также из вывода), мы получим разницу между df Used+Avail и Size:

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

Достаточно близко, особенно учитывая, что df округляет (использование df без -h и повторение вычислений оставляет необъясненной только 16 MiB разницы между Used+Avail и Size). Для кого зарезервированы блоки, также написано в выводе tune2fs. Это root. Это защитная сетка, чтобы гарантировать, что пользователи без root не смогут сделать систему полностью непригодной для использования, заполнив диск, а сохранение нескольких процентов дискового пространства неиспользуемым также помогает против фрагментации.

Теперь о разнице между размером, сообщенным df, и размером раздела. Это можно объяснить, взглянув на inodes. ext4 предварительно распределяет inodes, так что пространство не используется для данных файла. Умножьте Inode count на Inode size, и вы получите:

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

Inodes - это, по сути, записи каталога. Давайте спросим mkfs.ext4 о деталях (из man mkfs.ext4):

-i bytes-per-inode

Укажите соотношение байт/инод. mke2fs создает инод для каждого байта. bytes-per-inode байт пространства на диске. Чем больше байт на узел, тем меньше узлов будет создано. Это значение обычно не должно быть меньше, чем размер блока в файловой системы, так как в этом случае будет создано больше инодов, чем может быть чем может быть использовано. Следует иметь в виду, что изменить это соотношение невозможно. соотношение в файловой системе после ее создания, поэтому будьте внимательны при определении правильное значение для этого параметра. Обратите внимание, что изменение размера файловой системы изменяет количество inodes для поддержания этого соотношения.

Существуют различные предустановки, которые можно использовать для разных сценариев. На файловом сервере с большим количеством образов дистрибутива linux имеет смысл передать, например, -T bigfile или даже -T bigfile4. Что означает -T, определено в /etc/mke2fs.conf, в тех примерах и на моей системе:

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

Так что с -T bigfile4, количество намного меньше, чем по умолчанию (по умолчанию 16384 в моем /etc/mke2fs.conf). Это означает, что меньше места зарезервировано для записей каталогов, и больше места для данных. Когда у вас закончились inodes, вы не можете создавать новые файлы. Увеличение количества inodes в существующей файловой системе не представляется возможным. Таким образом, число inodes по умолчанию выбрано довольно консервативно, чтобы гарантировать, что средний пользователь не исчерпает inodes раньше времени.

Я только что понял это, глядя на свои цифры, дайте мне знать, если это работает (не работает) для вас ☺.