Чому ці файли в обсязі ext4 фрагментовані?


19

У мене є ext4розділ 900 Гб на (магнітному) жорсткому диску, який не має дефектів і поганих секторів. Розділ повністю порожній, за винятком порожнього lost+foundкаталогу. Розділ був відформатований за допомогою параметрів за замовчуванням, за винятком того, що я встановив кількість зарезервованих блоків файлової системи на 1%.

Я завантажив файл ~ 900 Мб xubuntu-15.04-desktop-amd64.isoв каталог точки монтажу розділу wget. Після закінчення завантаження я виявив, що файл розбитий на чотири фрагменти:

filefrag -v /media/emma/red/xubuntu-15.04-desktop-amd64.iso
Filesystem type is: ef53
File size of /media/emma/red/xubuntu-15.04-desktop-amd64.iso is 1009778688 (246528 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..   32767:      34816..     67583:  32768:            
   1:    32768..   63487:      67584..     98303:  30720:            
   2:    63488..   96255:     100352..    133119:  32768:      98304:
   3:    96256..  126975:     133120..    163839:  30720:            
   4:   126976..  159743:     165888..    198655:  32768:     163840:
   5:   159744..  190463:     198656..    229375:  30720:            
   6:   190464..  223231:     231424..    264191:  32768:     229376:
   7:   223232..  246527:     264192..    287487:  23296:             eof
/media/emma/red/xubuntu-15.04-desktop-amd64.iso: 4 extents found

Думаючи, що це може бути wgetякось знято, я видалив файл ISO із розділу, зробивши його знову порожнім, а потім скопіював файл ~ 700 Мб v1.mp4у розділ, використовуючи cp. Цей файл також був фрагментований. Він був розбитий на три фрагменти:

filefrag -v /media/emma/red/v1.mp4
Filesystem type is: ef53
File size of /media/emma/red/v1.mp4 is 737904458 (180153 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..   32767:      34816..     67583:  32768:            
   1:    32768..   63487:      67584..     98303:  30720:            
   2:    63488..   96255:     100352..    133119:  32768:      98304:
   3:    96256..  126975:     133120..    163839:  30720:            
   4:   126976..  159743:     165888..    198655:  32768:     163840:
   5:   159744..  180152:     198656..    219064:  20409:             eof
/media/emma/red/v1.mp4: 3 extents found

Чому це відбувається? І чи є спосіб запобігти цьому? Я думав, ext4мав на увазі стійкість до фрагментації. Натомість я вважаю, що він одразу фрагментує поодинокий файл, коли весь решта обсягу не використовується. Це здається гірше, ніж FAT32і NTFS.


4
Я намагаюся уявити, за яких обставин це може мати значення, і я підходжу порожнім.
Грег Хьюгілл

4
@GregHewgill: Мало значення, тому що я вважав це ненормальним. Тепер я знаю, що це нормально, це не має значення.
EmmaV

Відповіді:


17

3 або 4 фрагмента у файлі 900MB є дуже хорошим. Фрагментація стає проблемою, коли файл такого розміру має більше 100 фрагментів. Не рідкість жир або ntfs фрагментувати такий файл на кілька сотень.

Як правило, ви не побачите кращого, ніж щонайменше, у старих файлових системах ext4, оскільки максимальний розмір групи блоків становить 128 Мб, і тому кожні 128 Мб суміжний простір розбивається на кілька блоків для розподілу растрових зображень та таблиць inode для наступна блокова група. Більш недавня функція ext4 під назвою flex_bg дозволяє упакувати декілька (як правило, 16) блокових груп, варті цих таблиць разом, залишаючи довші тири виділених блоків, але залежно від вашого розповсюдження та якої версії e2fsprogs використовували для її форматування, ця опція може не використовувались.

Ви можете використовувати tune2fs -lдля перевірки функцій, увімкнених під час форматування вашої файлової системи.


Дуже цікаво. Я припускав, що всі таблиці inode тощо були на початку тома.
EmmaV

1
@EmmaV, поширюючи їх по диску, відносно близько до даних, на які вони посилаються, призводить до коротших пошуків та швидшого доступу до диска :)
hobbs

10

Я не можу по-справжньому відповісти, але думаю, що це може допомогти:

Зверніть увагу, як розмір кожного фрагмента має щонайбільше 32768 блоків (потужність 2, що повинно підняти прапор, що щось відбувається, а також дати вам підказку на те, що потрібно шукати).

Також варто зазначити, що ті фізичні зрушення між розширеннями досить близькі один до одного.

Від: Макет диска Ext4

Файлова система ext4 розділена на ряд груп блоків. Щоб зменшити труднощі з продуктивністю через фрагментацію, розподільник блоків дуже намагається утримувати блоки кожного файлу в одній групі, тим самим скорочуючи час пошуку. Розмір групи блоків вказаний у sb.s_blocks_per_group blocks, хоча він також може бути обчислений як 8 * block_size_in_bytes. З розміром блоку за замовчуванням 4KiB, кожна група буде містити 32 768 блоків, довжиною 128MiB

І далі вниз:

Перший інструмент, який ext4 використовує для боротьби з фрагментацією, - це багатоблоковий розподільник. Коли файл створюється вперше, блок-розподільник спекулятивно виділяє 8 Кбіт дискового простору для файлу [...] Другий пов'язаний трюк, який використовує ext4, - це затримка розподілу. За цією схемою, коли файлу потрібно більше блоків для поглинання записів файлів, файлова система відкладає рішення про точне розміщення на диску, поки всі брудні буфери не будуть записані на диск. Якщо не здійснювати певне розташування до тих пір, поки це абсолютно не потрібно (натиснути тайм-аут виконувати або викликати синхронізацію (), або ядро ​​закінчиться пам'яттю), сподіваємося, що файлова система може приймати кращі рішення щодо розташування.

Тому я б сказав, що розподільник дбає лише про локальність даних у групі блоків (ці 32K блоки), але не про сусідні групи один одного.


Перша цитата, яку ви дали, відповідає на моє запитання.
EmmaV

1
Кожна ступінь має максимум 32 к блоки, тому що це максимальна довжина, яку може охопити дескриптор міри. Екстенти - не фрагменти. Якщо ви помітили кілька фізичних блоків розширень, негайно слідкуйте за попередніми розмірами, і тому не складайте фрагмент (6 розрізів проти 3 фрагментів).
psusi
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.