ext4: Як обліковувати простір файлової системи?

Нещодавно я відформатував накопичувач 1,5 ТБ з наміром замінити ntfs на ext4.

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

df:

ext4 (ext3 & ext2 show the same behavior)
Filesystem      1K-blocks   Used  Available Use% Mounted on
/dev/sdb1      1442146364   71160 1442075204    1% /media/Seagate

ntfs (similar to all other options that gparted offers):
/dev/sdb1      1465137148  110700 1465026448    1% /media/Seagate

Ця різниця в блоках 1К означає значущий простір на 22 ГБ.

Я вже стратив

tune2fs -O \^has_journal
tune2fs -r 0
tune2fs -m 0

без дивного ефекту, оскільки це не впливає на блоки, яких просто немає.

Все-таки fdisk повідомляє, що розділ ext4 охоплює весь диск.

fdisk -l /dev/sdb:

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.

Disk /dev/sdb: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders, total 2930277168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1  2930277167  1465138583+  ee  GPT

Таким чином, наприклад, resize2fs повідомляє, що "нічого робити!"

dumpe2fs -h /dev/sdb1:
dumpe2fs 1.41.14 (22-Dec-2010)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          d6fc8971-89bd-4c03-a7cd-abdb945d2173
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      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 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              91578368
Block count:              366284288
Reserved block count:     0
Free blocks:              360518801
Free inodes:              91578357
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      936
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sat May 21 17:12:04 2011
Last mount time:          Sat May 21 17:15:30 2011
Last write time:          Sat May 21 17:24:32 2011
Mount count:              1
Maximum mount count:      32
Last checked:             Sat May 21 17:12:04 2011
Check interval:           15552000 (6 months)
Next check after:         Thu Nov 17 16:12:04 2011
Lifetime writes:          1372 MB
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
Default directory hash:   half_md4
Directory Hash Seed:      c334e6ef-b060-45d2-b65d-4ac94167cb09
Journal backup:           inode blocks

Для чого використовується пропущений простір?

Подивимось. Розмір пристрою - 1,465,138,583½ кБ = 1,500,301,909,504 Б. Файлова система складається з 366,284,288 блоків по 4096 B кожен, що становить 1,500,300,443,648 B. Я не знаю, для чого використовуються решта 1,465,856 B (1,4 МБ) (додаткові копії суперблоку «Я знаю, що на початку завантажувача є кілька кБ місця.)

Файлова система містить 91 578 368 входів по 256 байт, що займає 23 444 062 208 Б (близько 22 ГБ, підказка, підказка). Тоді є вміст файлу 1,442,146,364 кБ = 1,476,757,876,736 Б. На це припадає 23 444 062 208 B + 1,476,757,876,736 B = 1,500,201,938,944 B. Залишок розміру становить 98 504 704 B = 24,029 блоків, що в правильному діапазоні є розміром журналу.

Як бачите, все враховується. (Гаразд, майже все, але ми говоримо мегабайти, а не гігабайти.)

Перш за все, різниця у наявному просторі, який ви бачите, зовсім не означає, що є місце "витрачене"; він не витрачається даремно, оскільки він має принципове значення для функціонування файлової системи. Не слід порівнювати Ext4 та NTFS таким чином, не маючи великого "але", вказуючи всі конструктивні та структурні відмінності між файловими системами, а також специфіку кожної реалізації (наприклад, як кожен драйвер повідомляє про вільний простір шару VFS).

Уявіть собі розділ як величезний простір, куди ви можете помістити будь-які фрагменти даних, які у вас є. Якщо у вас є лише один фрагмент даних, розмір якого дорівнює розділу, ви можете просто записати його, починаючи з початку розділу і охолонути його. Але ти цього не робиш. Натомість у вас можуть бути тисячі невеликих файлів, і всі ці файли згруповані по-різному, і кожен файл пов'язаний з багатьма іншими невеликими фрагментами даних (ім'я, дата / час та дозволи) тощо. Ви повинні організувати великий простір розділ, щоб ви могли швидко та ефективно дістатись до всіх цих фрагментів даних. Крім того, ви повинні перейматися тим, як писати нові фрагменти даних та ефективно відкидати старі фрагменти даних. Вам потрібні структури даних .

І структури даних дуже багато . Деякі з них дуже німі, інші дозволяють швидше отримувати дані за рахунок більш повільних записів, інші дозволяють записувати швидше за рахунок читання, деякі все ще можуть бути дуже хорошими як при читанні, так і в записі, але вимагають довгих пауз і на холостому ходу, поки вона переставляє дані тощо

Ви, звичайно, хочете системи, яка:

1. Дуже швидко записувати інформацію на ньому;
2. Дуже швидко отримувати інформацію з неї;
3. Добре організовує та керує інформацією, що зберігається в ній;
4. Добре використовує простір (розділ), де зберігається файлова система;
5. Стійкий до апаратних проблем, щоб ви все-таки отримували більшість або всю інформацію про часткові збої в системі;
6. Є стійким до проблем із програмним забезпеченням, щоб помилка в додатку чи встановлений зловмисний додаток не знищила ваші дані назавжди;
7. Він стійкий до помилок людини, так що він пробачить вас, коли ви випадково наказали системі видалити щось, чого не слід (він же сміттєвий / кошик для сміття).

Високопродуктивні файлові системи дозволяють дуже швидко читати і записувати за рахунок деякого простору. Деякі з найшвидших структур даних, що використовуються у файлових системах, як хеш-таблиці та B-дерева , дуже складні, і вони залишають більше місця, ніж це фактично використовується, щоб дозволити дуже швидкий доступ.

Ext4 має й інші важливі властивості. У файловій системі немає єдиного пункту відмови. Існує багато копій критичних даних, що поширюються через розділ, тоді як деякі інші файлові системи (я не можу сказати для NTFS) можуть зробити всі ваші дані нечитабельними, якщо збій трапиться в потрібному місці. Крім того, Ext4 залишає багато місця для ваших даних безпосередньо на етапі створення файлової системи, в той час як NTFS росте з вашими даними.

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! 
The util fdisk doesn't support GPT. Use GNU Parted.

Це повідомлення вказує на те, що диск використовує розділення в стилі GPT, і цей fdiskінструмент розуміє лише застарілий стиль MBR.

Щоб запобігти випадковим переформатуванням, якщо диски з розділеними GPT підключені до старих систем, не знаючих GPT, схема розподілу GPT включає "захисну MBR": повністю підроблену таблицю розділів, яка в основному повідомляє "цей диск повністю використовується типом розділу, не знаю нічого про "будь-яку операційну систему чи інструмент, який розуміє лише розбиття MBR.

Щоб отримати точне відображення таблиці розділів /dev/sdb, використовуйте:

parted /dev/sdb print