Почему эти файлы в томе ext4 фрагментированы?

19

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

Я загрузил файл ~ 900MB 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.

EmmaV
источник
4
Я пытаюсь представить, при каких обстоятельствах это может иметь значение, и я выхожу пустым.
Грег Хьюгилл
4
@GregHewgill: это имело значение, потому что я думал, что это ненормально. Теперь я знаю, что это нормально, это не имеет значения.
EmmaV

Ответы:

17

3 или 4 фрагмента в файле размером 900 Мб - это очень хорошо. Фрагментация становится проблемой, когда файл такого размера имеет более 100 фрагментов. Для fat или ntfs нередко разбивать такой файл на несколько сотен частей.

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

Вы можете использовать, tune2fs -lчтобы проверить, включены ли функции, когда ваша файловая система была отформатирована.

psusi
источник
Очень интересно. Я предположил, что все таблицы инодов и т. Д. Были в начале тома.
EmmaV
1
@EmmaV, распределяя их по диску, относительно близко к данным, на которые они ссылаются, приводит к сокращению числа
запросов
10

Я не могу действительно ответить, но я думаю, что это может помочь:

Обратите внимание, что каждый фрагмент имеет максимальный размер 32768 блоков (степень 2, которая должна поднять флаг, указывающий, что что-то происходит, а также подсказку для поиска).

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

От: Ext4 Расположение диска

Файловая система ext4 разбита на серию групп блоков. Чтобы уменьшить проблемы с производительностью из-за фрагментации, распределитель блоков очень старается удерживать блоки каждого файла в одной группе, тем самым сокращая время поиска. Размер группы блоков указан в sb.s_blocks_per_group blocks, хотя он также может быть рассчитан как 8 * block_size_in_bytes. При размере блока по умолчанию 4 КБ каждая группа будет содержать 32 768 блоков длиной 128 МБ.

И дальше вниз:

Первым инструментом, который ext4 использует для борьбы с фрагментацией, является многоблочный распределитель. Когда файл создается впервые, распределитель блоков спекулятивно выделяет 8 КБ дискового пространства для файла [...] Второй связанный трюк, который использует ext4, - это отложенное выделение. Согласно этой схеме, когда файлу требуется больше блоков для поглощения записи файла, файловая система откладывает принятие решения о точном размещении на диске, пока все грязные буферы не будут записаны на диск. Не фиксируя конкретное размещение до тех пор, пока оно не станет абсолютно необходимым (тайм-аут фиксации, или вызывается sync (), или ядру не хватает памяти), можно надеяться, что файловая система сможет принимать более точные решения о местоположении.

Поэтому я бы сказал, что распределитель заботится только о локальности данных в группе блоков (эти блоки по 32 КБ), но не о том, что группы блоков являются смежными друг с другом.

outlyer
источник
Первая цитата, которую вы дали, отвечает на мой вопрос.
EmmaV
1
Каждый экстент имеет максимум 32 000 блоков, потому что это максимальная длина, которую может охватить дескриптор экстента. Экстенты не являются фрагментами. Если вы заметили, что некоторые из физических блоков экстентов сразу же следуют за предыдущими, и поэтому не составляют фрагмент (6 экстентов против 3 фрагментов).
psusi