Создавая резервную копию раздела 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 для всего, кроме моего раздела.
Благодарность!
источник
Ответы:
Здесь происходит несколько вещей. gparted сообщает о фактическом использованном / свободном пространстве. Ядро уменьшает доступное количество зарезервированным пространством. После удаления зарезервированного пространства количество свободных мест не изменилось, поскольку зарезервированные блоки уже были свободны; просто пользователи без прав root не могут проникать в это пространство, чтобы не создавать проблем при заполнении диска. Числа гномов немного ненадежны из-за ошибки . Вместо того, чтобы сообщать об используемом пространстве, которое ядро сообщает (и показывает df), оно вычисляет его, вычитая свободное пространство из общего количества. Это заставляет его показывать зарезервированное пространство как использованное.
Недостающие 4 ГБ фактически используются для служебной нагрузки fs для ext4. NTFS изначально выделяет небольшое количество места для MFT и увеличивает его по мере необходимости. Тем не менее, ряд файловых систем ext выделяет пространство для таблицы inode (грубый эквивалент MFT) во время форматирования и не может расти. Пробел, отсутствующий в сообщенном общем пространстве, является таблицей inode. Оставшийся бит занятого пространства - из журнала (обычно 128 МБ) и инодов изменения размера.
источник
df
даже с помощью sudo отображается общая емкость (247 ГБ) и используемое пространство (188 МБ), например, Nautilus. Так что, если это ошибка, это не только гном.stat -f /media/BACKUP
.Прежде всего, зарезервированные блоки не являются блоком, используемым для внутреннего управления файловой системой.
Зарезервированные блоки просто зарезервированы для того
root
, чтобы гарантировать, что службы, использующие файлы в этом разделе, не могут быть исключены из пространства некоторым пользователем без прав администратора, заполняющим все пространство.Даже без зарезервированных блоков (
-m 0
) всегда есть часть пространства, используемого для внутреннего управления файловой системой, я не могу сказать, сколько, у меня нет таких глубоких знаний.Кроме того, Gparted выполняется как
root
, поэтому он видит зарезервированные блоки как свободные. Наутилус , исполняемый как пользователь, видит их как несвободные.Хорошо, ответ @psusi очень ясен, мне нечего добавить.
источник
Попробуйте уменьшить размер раздела на несколько мегабайт, используя gparted, а затем снова увеличьте его до исходного размера. Это может привести к тому, что другие приложения будут правильно читать размеры. Я недавно исправил ошибку 50Gb таким образом!
источник