размер раздела ext4 / несоответствия свободного пространства
При создании резервного раздела на 250 ГиБ для моих данных я заметил много несоответствий между размером раздела, о котором сообщают, и свободным пространством в Наутилусе, gParted, df, tune2fs, и т.д.
Сначала я думал, что это был гибибайт / беспорядок ГБ.Как бы не так.
Затем я думал, что это могли быть зарезервированные блоки ext4.Как бы не так.
Я полностью озадачен. Вот некоторые изображения. Вот шаги:
- Во-первых, NTFS. 524 288 000 секторов x 512 байтов/секторы = 268435456000 байтов = 268,4 ГБ = 250 гибибайт.
Наутилус говорит "Общую мощность: 250,0 ГБ" (даже при том, что на самом деле гибибайт, не ГБ). Кроме того незначительного mislabeling, пока неплохо
- Теперь, тот же раздел, форматированный как 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 используемый? Shouldnt это быть ~12GB? И общая мощность является все еще неправильной. Таким образом, я работал 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
65 536 000 общих блоков * 4 096 байтов/блоки = 268435456000 байтов = 268,4 ГБ = 250 гибибайт. Это соответствует gparted.
3 276 800 зарезервированных блоков = 13 421 772 800 байтов = 13,4 ГБ = 12,5 гибибайт. Это (снова, вид) соответствует Наутилусу.
64 459 851 свободный блок = 264 027 549 696 байтов = 264,0 ГБ = 245,9 гибибайт. Почему? Shouldnt это быть или 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
Похож я сделал. Пространство Avaliable повысилось с 233 до 245,9 гибибайт. gparted не заботился вообще, показывая точно ту же информацию! (бесполезный для регистрации идентичного снимка экрана)
Какая огромная путаница!
Я пытался зарегистрировать его настолько лучше всего, как я мог... Так, кто-то может дать мне какой-либо ключ к разгадке на том, что продолжается здесь?
- Что те таинственные 4,11 гибибайта пропускают от NTFS-> ext4 форматирование?
- Почему существует столько несоответствий между gparted, Наутилусом, tune2fs, df?
- Что не так с моей математикой? (вопросы полужирным рассеяли это сообщение),
Любая справка ценится. В то время как я не могу изобразить то, что продолжается, я serilously рассматриваю отказывание ext4 в пользу NTFS для всего, но моего / раздел.
Спасибо!
4 ответа
Здесь происходит несколько вещей. gparted сообщает о фактическом использовании / свободном пространстве. Ядро уменьшает доступное количество на зарезервированное пространство. После того, как вы удалили зарезервированное пространство, количество свободных блоков не изменилось, поскольку зарезервированные блоки уже были свободны; просто пользователям, не являющимся root, не разрешается вторгаться в это пространство, чтобы они не создавали проблемы, заполняя диск. Номера гномов немного нестабильны из-за ошибки . Вместо того, чтобы сообщать об использованном пространстве, которое сообщает ядро (и показывает df), оно вычисляет его, вычитая свободное пространство из общего количества. Это приводит к тому, что зарезервированное пространство отображается как использованное.
Фактически используемые недостающие 4 ГБ - это накладные расходы fs для ext4. NTFS изначально выделяет небольшой объем пространства для MFT и при необходимости увеличивает его. Тем не менее, серия файловых систем ext выделяет пространство для таблицы inode (приблизительный эквивалент MFT) во время форматирования и не может увеличиваться. Пространство, отсутствующее в сообщенном общем объеме, - это таблица индексных дескрипторов. Оставшийся бит занятого пространства - это журнал (обычно 128 МБ) и индексные дескрипторы изменения размера.
Прежде всего, зарезервированные блоки не являются блоком, используемым для внутреннего управления файловой системой.
Зарезервированные блоки просто зарезервированы для root , что касается убедитесь, что службы, использующие файлы в этом разделе, не могут быть исключены из пространства каким-либо пользователем без прав администратора, заполняющим все пространство.
Даже без зарезервированных блоков ( -m 0 ) всегда есть часть пространство, используемое для внутреннего управления файловой системой, я не могу сказать, сколько, у меня нет таких глубоких знаний.
Кроме того, Gparted выполняется как root , поэтому он видит зарезервированные блоки как бесплатно. Nautilus , запущенный от имени пользователя, считает их несвободными.
Хорошо,@psusi ответ очень ясен, мне нечего добавить.
Попробуйте уменьшить размер раздела на несколько мегабайт с помощью gparted, а затем снова увеличьте его до исходного размера. Это может привести к тому, что другие приложения будут правильно считывать размеры. Я недавно исправил ошибку 50 ГБ таким образом!
После разделения моего нового диска 8 ТБ с помощью gparted, он сообщил:
Size: 7.28 TiB
Used: 59.76 GiB <-- Huh?
Unused: 7.22 TiB
Что такое почему я оказался здесь. Теперь позвольте начать расследование.
Запуск sudo fdisk / dev / sdc (где / dev / sdc - мой новый диск)
показывает:
Disk /dev/sdc: 7,3 TiB, 8001563222016 bytes, 15628053168 sectors
Units: sectors of 1 * 512 = 512 bytes
...
Disklabel type: gpt
Обратите внимание, что 15628053168 * 512 = 8001563222016.
С этого момента давайте работать в количестве СЕКТОРОВ (которые составляют 512 байт) и работать исключительно с шестнадцатеричной системой записи. Это дает нам,
fdisk (real values)
Disk size: 3a3812ab0
Кроме того, fdisk дает нам таблицу разделов:
Device Start End Sectors Size Type
/dev/sdc1 2048 15628052479 15628050432 7,3T Linux filesystem
Давайте переведем это тоже в шестнадцатеричный (он уже в секторах):
/dev/sdc1 800 3a38127ff 3a3812000 7.277378082275390625 TiB
(Это значение TiB точное ; но в десятичном формате. Это показывает, почему было напечатано 7.3).
Первые секторы 0x800 зарезервированы для основной загрузочной записи (MBR) и таблица разделов (введите gpt, поскольку она была создана gparted, и я выбираю чтобы использовать этот тип там).
Сектор End является включающим, так что действительно
3a38127ff + 1 - 800 = 3a3812000
Но почему он был выбран? Ну, потому что gparted округлил все до 1 МиБ границы (он сказал),это секторы 0x800 (1024 * 1024/512 в шестнадцатеричном формате).
Тем не менее, почему он не выбрал 3a3812fff в качестве последнего сектора? Ну, поскольку этого не существует, общий размер диска составляет 3a3812ab0, как мы видели раньше.
Хорошо, поэтому нам нужно немного места в начале для MBR и таблицы разделов, но мы хотим только начать и закончить разделы с 0x800 границ, поэтому первый сектор - 800, а последний - 3a38127ff. Это приводит к общему размеру раздела из 3a3812000 секторов, или 7,28 ТиБ, как сообщает gparted (8001561821184 байта в десятичном формате).
Тип файловой системы на нем - ext4.
Начнем с его монтирования и теперь будем работать в секторах в DECIMAL:
sudo mount -t ext4 /dev/sdc1 /mnt/newdisk
df -B512 | grep sdc1
/dev/sdc1 15502817864 102728 14721279848 1% /mnt/newdisk
Итак, df отчеты в секторах и в шестнадцатеричном формате:
df Size: 15502817864 sectors (= 7937442746368 bytes = 7.219... TiB).
df Used: 102728 sectors (= 52596736 bytes = 50.16 MiB).
df Available: 14721279848 sectors (= 7537295282176 bytes = 6.855... TiB).
Следовательно, сообщаемый размер составляет 8001561821184 - 7937442746368 = 64119074816 = 59,716 ГиБ меньше , чем размер раздела, сообщаемый fdisk!
Итак, как работает ext4 ?
Мы можем быстро получить большой объем информации.
sudo dumpe2fs -h /dev/sdc1
Самый важный вывод -
Inode count: 244191232
Block count: 1953506304
Reserved block count: 97675315
Free blocks: 1937839392
Free inodes: 244191221
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 558
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 4096
Inode blocks per group: 256
Flex block group size: 16
First inode: 11
Inode size: 256
Required extra isize: 32
Desired extra isize: 32
Journal size: 1024M
Journal length: 262144
Обратите внимание, что количество блоков показывает полный размер раздела. Один блок составляет 4096 байт, то есть 1953506304 * 4096 = 8001561821184.
Очевидно, мы ищем блоки, которые нам недоступны. Исходя из того, что df сообщает как Доступные (7537295282176/4096 = 1840159981 доступных блоков), то есть 113346323 блоков, которые недоступны.
Журнал существует из 262144 блоков, поэтому ... 113346323 - 262144 = 113084179 блоков в очереди.
У нас есть 558 зарезервированных блоков GDT ... 113083621 блок в очереди.
Число "групп" в fs равно 'общее количество inodes' / 'inodes per group' = 244191232 / 4096 = 59617.
inodes размером 256 байт составляют 244191232 * 256/4096 = 15261952 блока, так что 113083621 - 15261952 = 97821669 блоков, которые нужно уйти.
У нас нет вариантов, очевидно, зарезервированный блок счетчик тоже недоступен, что составляет 97675315 .. так что остается 97821669 - 97675315 = 146354 блока, которые недоступны, что мы еще не объяснили. Это все еще 571,7 МБ, или ~ 2,455 блока на группу, но не НАСТОЛЬКО по сравнению с 59,76 ГБ, которые мы должны были объяснить.
Выполнение следующей команды:
cat /proc/fs/ext4/sdc1/mb_groups | sed -e 's/^#.*://' | sort | uniq -c | sort -rn | sed -e 's/^\(..............\).*/\1/' | grep -v free
Мы получаем количество (первый столбец) групп, которые имеет N свободных блоков (второй столбец):
55860 32768
3724 28640
22 31743
8 0
1 8958
1 28639
1 27609
Очевидно, что максимальное количество свободных блоков на группу составляет 32768 (большинство из них), что также является тем, что сообщил dumpe2fs (блоков на группу).
Итак. , позвольте мне преобразовать эту таблицу в «Используется» в байтах, вычтя второй столбец из 32768 и умножив его на 4096 байтов. Затем я получаю
3724 16908288
22 4198400
8 134217728
1 97525760
1 16912384
1 21131264
и 3724 * 16908288 + 22 * 4198400 + 8 * 134217728 + 97525760 + 16912384 + 21131264 = 64268140544 или 59,85 ГиБ.
SUMMARY
Unavailable blocks Reason
97675315 Reserved block count (5%)
15261952 inodes (0.78%)
262144 journal (0.013%)
146354 Unexplained (0.007%)
558 Reserved GDT blocks (0%)
Начнем с изменения количества зарезервированных блоков на 0, потому что это Жесткий диск предназначен для длительного хранения, и меня действительно не волнует, что произойдет, если он заполнится (я делаю, но моя система по-прежнему будет работать безупречно).
sudo umount /dev/sdc1
sudo tune2fs -r 0 /dev/sdc1
dumpe2fs теперь сообщает:
Reserved block count: 0
но что более важно,
df -B512 | grep sdc1
/dev/sdc1 15502817864 102728 15502682368 1% /mnt/newdisk
aka
df Available: 15502682368 sectors (= 7937373372416 bytes = 7.22... TiB)!
Мы также можем уменьшить количество inodes, но это разумно только в том случае, если вы уверены, что они вам не понадобятся; например, когда вы будете хранить на диске только большие файлы. Количество inodes - это примерно количество файлов + каталогов, которые вы можете хранить на диске. Итак, наличие 244191232 позволит мне хранить на этом диске файлы со средним размером 32 КБ (32504 байта). Вместо этого я намерен хранить на нем в основном файлы размером примерно от 1 до 2 ГБ ... Так что да, я думаю, что могу безопасно уменьшить количество inode, скажем, в 10 раз.
Итак, я решил переформатировать свой раздел (винтовой gparted, все, что мне нужно, это таблица разделов, а не файловая система):
sudo mkfs.ext4 -b 4096 -e remount-ro -i 325040 -j -L '/opt/verylarge' -m 0 -t ext4 -T big -U 48c6a937-aea3-42a0-a69c-c24d0dc65179
После чего я получил
Inode count: 24800672
Block count: 1953506304
Reserved block count: 0
Free blocks: 1951529866
Free inodes: 24800661
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Reserved GDT blocks: 1024
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 416
Inode blocks per group: 26
Flex block group size: 16
First inode: 11
Inode size: 256
Required extra isize: 32
Desired extra isize: 32
Journal size: 1024M
Journal length: 262144
df -H
Filesystem Size Used Avail Use% Mounted on
/dev/sdc1 8,0T 97M 8,0T 1% /mnt/newdisk
Я не знаю, откуда этот 1%, но я доволен своим 8, 0 ТБ :)