Размер раздела ext4 / расхождения в свободном пространстве

14

Создавая резервную копию раздела 250 ГБ для моих данных, я заметил много несоответствий между указанным размером раздела и свободным пространством в Nautilus, gParted, df, tune2fs и т. Д.

Сначала я подумал, что это путаница с GiB / GB. Это не было .

Тогда я подумал, что это могут быть зарезервированные блоки ext4. Это не было .

Я полностью озадачен. Вот несколько изображений. Вот шаги:

  • Во-первых, NTFS. 524288000 секторов x 512 байт / сектор = 268435456000 байт = 268,4 ГБ = 250 ГиБ.

введите описание изображения здесь введите описание изображения здесь

Наутилус говорит: « Общая емкость: 250,0 ГБ » (хотя на самом деле это ГиБ, а не ГБ). Помимо этого незначительного неправильного обозначения, до сих пор, так хорошо

  • Теперь тот же раздел, отформатированный как ext4 с помощью gparted:

введите описание изображения здесь

Первый, последний и общий секторы одинаковы. Это тот же раздел 250 ГБ. Используемый размер 4,11 ГБ (возможно, зарезервированные блоки?)

введите описание изображения здесь

Нет. Похоже, зарезервированные блоки 12,7 ГиБ (~ 5%. Ой! ). Но ... почему общая емкость сейчас составляет всего 246,1 ГБ ??? , Эта разница (вроде) соответствует 4.11 ГиБ, сообщаемым gparted. Но ... если это не из зарезервированных блоков, что это? И почему gparted не сообщил, что 12,7 ГБ использованного пространства?

$ df -h /dev/sda5
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5             247G  188M  234G   1% /media/BACKUP

dfсоответствует Наутилусу в сообщенном свободном пространстве. Но .. только 188M используется? Разве это не должно быть ~ 12 ГБ? И общая емкость все еще не так. Поэтому я побежал, tune2fsчтобы найти подсказки. (несоответствующий вывод опущен)

$ sudo tune2fs -l /dev/sda5
tune2fs 1.41.12 (17-May-2010)
Filesystem volume name:   BACKUP
Filesystem UUID:          613d592e-47f5-4206-96a7-210090d340ef
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Filesystem state:         clean
Filesystem OS type:       Linux
Block count:              65536000
Reserved block count:     3276800
Free blocks:              64459851
First block:              0
Block size:               4096

Всего 65536000 блоков * 4096 байт / блок = 268435456000 байт = 268,4 ГБ = 250 ГиБ. Это соответствует gparted.

3276800 зарезервированных блоков = 13421772800 байт = 13,4 ГБ = 12,5 ГиБ. Это (опять же, вроде) соответствует Наутилусу.

64459851 свободных блоков = 264027549696 байт = 264,0 ГБ = 245,9 ГиБ. Почему? Разве это не должно быть 250-12,5 = 237,5 (или 250- (12,5 + 4,11) = ~ 233)?

Удаление зарезервированных блоков:

$ sudo tune2fs -m 0 /dev/sda5
tune2fs 1.41.12 (17-May-2010)
Setting reserved blocks percentage to 0% (0 blocks)

$ sudo tune2fs -l /dev/sda5
tune2fs 1.41.12 (17-May-2010)
Filesystem volume name:   BACKUP
Filesystem UUID:          613d592e-47f5-4206-96a7-210090d340ef
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Filesystem state:         clean
Filesystem OS type:       Linux
Block count:              65536000
Reserved block count:     0
Free blocks:              64459851
Block size:               4096

Как и ожидалось, то же количество блоков, 0 зарезервированных блоков, но ... одинаковые свободные блоки ? Разве я только что освободил 12,5 ГиБ?

$ df -h /dev/sda5
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5             247G  188M  246G   1% /media/BACKUP

введите описание изображения здесь

Похоже, я сделал. Доступное пространство увеличилось с 233 до 245,9 ГиБ. gparted не заботился вообще, показывая точно такую же информацию! (бесполезно публиковать идентичный скриншот)

Какой огромный беспорядок!

Я пытался документировать это как можно лучше ... Итак, пожалуйста, кто-нибудь может подсказать мне, что здесь происходит?

  • Чего не хватает этим загадочным 4.11 GiB в NTFS -> ext4 форматировании?
  • Почему так много расхождений между gparted, Nautilus, tune2fs, df?
  • Что не так с моей математикой? (вопросы, выделенные жирным шрифтом разбросаны по этому посту)

Любая помощь приветствуется. Хотя я не могу понять, что происходит, я серьезно рассматриваю возможность отказа от ext4 в пользу NTFS для всего, кроме моего раздела.

Благодарность!

MestreLion
источник
askubuntu.com/questions/24371/…
Ури Эррера
@Uri Herrera: ты действительно прочитал мой вопрос или хотя бы первые несколько строк? Это не проблема GiB / GB. Размер раздела составляет 268,4 ГБ = 250,0 ГБ, а не 246,1
MestreLion
1
Другой ответ вы посмотрите на можете: askubuntu.com/questions/5335/...
enzotib
1
Смотрите также ext4: Как учесть пространство файловой системы?
Жиль "ТАК - перестань быть злым"

Ответы:

13

Здесь происходит несколько вещей. gparted сообщает о фактическом использованном / свободном пространстве. Ядро уменьшает доступное количество зарезервированным пространством. После удаления зарезервированного пространства количество свободных мест не изменилось, поскольку зарезервированные блоки уже были свободны; просто пользователи без прав root не могут проникать в это пространство, чтобы не создавать проблем при заполнении диска. Числа гномов немного ненадежны из-за ошибки . Вместо того, чтобы сообщать об используемом пространстве, которое ядро ​​сообщает (и показывает df), оно вычисляет его, вычитая свободное пространство из общего количества. Это заставляет его показывать зарезервированное пространство как использованное.

Недостающие 4 ГБ фактически используются для служебной нагрузки fs для ext4. NTFS изначально выделяет небольшое количество места для MFT и увеличивает его по мере необходимости. Тем не менее, ряд файловых систем ext выделяет пространство для таблицы inode (грубый эквивалент MFT) во время форматирования и не может расти. Пробел, отсутствующий в сообщенном общем пространстве, является таблицей inode. Оставшийся бит занятого пространства - из журнала (обычно 128 МБ) и инодов изменения размера.

psusi
источник
Спасибо, +1 за решение некоторых загадок! Но если ~ 4 ГБ являются накладными расходами файловой системы, почему некоторые из них (3,9 ГБ) вычитаются из общего пространства, а 188 МБ отображаются как фактически используемые? Какие (или оба) накладные расходы? И почему обрабатывается по-разному? Кроме того, dfдаже с помощью sudo отображается общая емкость (247 ГБ) и используемое пространство (188 МБ), например, Nautilus. Так что, если это ошибка, это не только гном.
MestreLion
Я думал, что 188 МБ были накладными (по сравнению с 72 МБ от NTFS). Но если накладные расходы NTFS со временем возрастут, значит ли это, что Nautilus позже сообщит о сокращении общей емкости ?
MestreLion
Исправление: df всегда показывает доступное пространство, независимо от того, кто его запускает. Чтобы увидеть свободное пространство (== доступное пространство + зарезервированное пространство), используйте stat -f /media/BACKUP.
Мариус Гедминас
Отредактированный ответ, чтобы уточнить. И я считаю, что NTFS будет просто сообщать о более занятом пространстве, а не сокращать общее количество по мере роста MFT. @ Мариус, это тоже не правильно. statfs () и, следовательно, и df, и stat -f оба показывают доступное пространство без учета зарезервированных блоков. Я мог бы поклясться, что он также настроен на квоту и варьировал свой ответ в зависимости от вызывающего пользователя, но вы правы в этом; она не учитывает квоту и не заботится о том, как ее называет пользователь.
псуси
@psusi: у меня ~ 3,9 ГБ таблицы инодов и ~ 188 МБ журнала + что-нибудь? И Наутилус вычитает таблицу индексов из общего размера, в то время как сообщает журнал как использованное пространство? И gparted сообщает о них как о едином 4.11 ГБ используемого пространства? Это верно? Если это так, я просто хотел бы, чтобы Наутилус обрабатывал оба заголовка одинаково ... либо оба вычитали из общего количества, либо оба считали "использованным пространством" (предпочтительно).
MestreLion
7

Прежде всего, зарезервированные блоки не являются блоком, используемым для внутреннего управления файловой системой.

Зарезервированные блоки просто зарезервированы для того root, чтобы гарантировать, что службы, использующие файлы в этом разделе, не могут быть исключены из пространства некоторым пользователем без прав администратора, заполняющим все пространство.

Даже без зарезервированных блоков ( -m 0) всегда есть часть пространства, используемого для внутреннего управления файловой системой, я не могу сказать, сколько, у меня нет таких глубоких знаний.

Кроме того, Gparted выполняется как root, поэтому он видит зарезервированные блоки как свободные. Наутилус , исполняемый как пользователь, видит их как несвободные.

Хорошо, ответ @psusi очень ясен, мне нечего добавить.

enzotib
источник
Хм, очень информативно, +1. По крайней мере, это решает некоторые проблемы, которые я нашел. Если рассматривать зарезервированные блоки как «ограничение» для не-root вместо «используемых блоков», то показания gparted, df и tune2fs согласуются (и имеют смысл). Но некоторые вопросы все еще остаются, особенно 4 ГБ используемого пространства / общая емкость.
МестреЛион
1
Кроме того, я где-то читал (один из тех старых «почему вам не нужно дефрагментировать раздел Linux каждый месяц», возможно, HOWTO?), Что резервирование 5% пространства для root дает некоторое пространство для дыхания алгоритмам выделения extN и, следовательно, избегает фрагментация.
Мариус Гедминас
1

Попробуйте уменьшить размер раздела на несколько мегабайт, используя gparted, а затем снова увеличьте его до исходного размера. Это может привести к тому, что другие приложения будут правильно читать размеры. Я недавно исправил ошибку 50Gb таким образом!

джим берез
источник