Логика размещения файлов в ФС

cast i-rinat, ты вроде разбираешься в работе ФС

по порядку, от начала раздела к концу

Это вот щас про FAT было. extN отличается как по структуре «файлвой» и «инодной» таблицам, так и по размещению самих данных.

Ну, что по структуре отличается - это ясно, а по логике заполнения данными?

Я помню на винде когда запускаешь дефрагментатор на NTFS - там обычно куча данных в начале раздела, изрядная порция в середине, и ошмётки то там, то сям разбросаны.

А вот в Линуксах как - хз. Может, есть какая-нибудь тулза, которая так же нарисовала бы графическую карту расположения данных на ext/xfs?

А вот в Линуксах как - хз.

Здесь Ринат нужен. Как он я разъяснить не смогу. Жди, когда он откликнется.

А вот в Линуксах как - хз. Может, есть какая-нибудь тулза, которая так же нарисовала бы графическую карту расположения данных на ext/xfs?

https://github.com/i-rinat/fragview

https://github.com/i-rinat/fragview

Прога хорошая. Но для ТС это будет проблемой: gtkmm-3.0 glibmm-2.4

Да не, уже поставил из aur, на корне прикольную картинку выдало))

На ext4:

начало

середина

конец

На последовательное заполнение как-то непохоже.

уже поставил из aur

И всё-таки зря Ринат её к gtk прикрутил, лучше б к ncurses и libpng. Потеря интерактивности не принципиальна.

На ext4:

Не достаточно равномерное, ты случаем e4defrag не применял?

На почти полностью заполненном /media/mix ещё прикольнее. Что за диагональные просветы в 1-2 клетки? Они стабильно на протяжении всего раздела.

На этом ssd - нет, ни разу.

На последовательное заполнение как-то непохоже.

Ну, там же должен быть какой-то чудесный алгоритм, который, якобы, минимизирует фрагментирование ;)

На последовательное заполнение как-то непохоже

Насколько я помню, там есть группы и каждая группа заполняется по отдельности. Это сделано, чтобы группы ложились на цилиндры и чтение-запись в группу т.о. происходит без перемещения головок.

Насколько я помню, там есть группы и каждая группа заполняется по отдельности

Тоже что-то такое припоминаю

чудесный алгоритм, который, якобы, минимизирует фрагментирование

Чушь собачья! Задача по размещению данных на диске разрабами extX ставилась совсем по другому. «минимизирует фрагментирование» - это уже маркетологи прикрутили.

Вообще я так понимаю, что дизайн ext2 был частично позаимствован с ufs из bsd. Последняя хорошо описана в литературе. Или тебе вот прям конкретика ext2-4 интересует?

Интересует поведение ext4 и xfs на актуальных версиях ядра.

Это https://www.kernel.org/doc/html/latest/filesystems/ext4/index.html читал?

Читанул это: https://www.kernel.org/doc/html/latest/filesystems/ext4/overview.html#block-a... и так и не смог сделать однозначного вывода, раскидывает ли ext4 данные по разделу, или нет. Вроде как да.

раскидывает ли ext4 данные по разделу

Меня в этом вопросе больше интересовало насколько эффективно размещается «файловая» и «инодная» таблицы на диске. И есть ли тулзы, способные повлиять на это размещение. Ответа так и не нашёл.

Согласно этому:

The third trick that ext4 (and ext3) uses is that it tries to keep a file's data blocks in the same block group as its inode.

The fourth trick is that all the inodes in a directory are placed in the same block group as the directory, when feasible

Иноды рядом с данными хранятся.

Иноды рядом с данными хранятся.

Да, но эффективно ли? И возможность повлиять на размещение?

e4defrag не применял

а в чем подвох? я применял несколько раз, но только сканировал и он всегда говорит, что ничего дефрагментировать не надо...

а в чем подвох?

«Нарушает» «равномерное» размещение файлов. Правда не сильно.

Если нужно растащить фильм ffmpeg'ом на кадры и потом последовательно скормить их какой-нибудь софтине, рекомендую xfs. Extы на огромном количестве файлов начинают неистово тормозить даже при, казалось бы, линейном чтении.

Написано же,

1) старается размещать данные рядом с инодами

2) старается группировать иноды на основе каталогов

3) откладывает распределение пространства насколько возможно, до сброса буферов

Так что да, заполняет не последовательно.

Просветы - очевидно неиспользуемые иноды в каждой группе блоков. Называться это может по-разному в зависимости от ФС (cylinder groups, allocation groups, block groups), но суть одна.

Про XFS читал, что она каждую новую директорию создает в новой allocation-группе.

Extы на огромном количестве файлов начинают неистово тормозить

А вот здесь как раз и возникают вопросы эффективного размещения таблиц. Если ffmpeg-ом добавлять в «папку» по «кадру» (как собстно и происходит), то влегкую получаем «тормоза». А если скопировать «тормознутую папку», то в одних «случаях» тормоза продолжают наблюдаться, а в других - нет.

Любая read-write ФС куда угодно может записывать. Иначе быстро получишь «no space left on device», который не будет лечиться даже удалением файлов :)

Насколько помню из опыта работы на древних дисках под виндой, NTFS, после того как раздел хорошо заполнится файлами, фрагментировала не только файлы, но для полного счастья еще и $MFT. Отложенного распределения кластеров не было, а встроенный дефрагментатор оставлял промежутки после себя. Всё это приводило к комбо-эффекту, и если однажды запустить дефрагментатор, пользователь подсаживался на дефрагментатор навсегда.

Жуткие воспоминания. :D

Боже, как хорошо жить в будущем!

В обоих случаях свежеотформатированные разделы, ессно. При первых признаках фрагментации магия работать перестаёт.

При первых признаках фрагментации магия работать перестаёт.

Очередная чушь про фрагментацию! Дайте тулзу, способную рихтовать «файловую» и «инодную» таблицы, и я буду в Вас с вашей дефрагментацией пальцем тыкать и смеяться во весь голос.

Так что да, заполняет не последовательно

Ну там действительно не ясен такой момент, что если ты кидаешь файлы в одну директорию и группа блоков в 128М заполнилась. Как выбирается следующая группа блоков? Хотя, если такие подробности нужны, то надёжнее всего просто глянуть исходники.

Тебе надо - ты и тыкай, я-то тут каким боком? Магия работает только один раз, при последовательной записи на чистый раздел. Любые удаления/изменения её довольно быстро херят.

Любые удаления/изменения её довольно быстро херят.

Ну мы примерно об одном и том же говорим в принципе. Только я говорю о том, что мне плевать как данные располагаются на диске, лишь бы таблицы располагались эффективно, а ты упираешься в расположение самих данных.

e4rat?

Он не «сканирует» а дефрагментирует.

Вот, кстати, man mke2fs:

packed_meta_blocks[= <0 to disable, 1 to enable>]
Place the allocation bitmaps and the inode table at the beginning of the disk. This option requires that the flex_bg file system feature to be enabled in order for it to have effect, and will also create the journal at the beginning of the file system. This option is useful for flash devices that use SLC flash at the beginning of the disk. It also maximizes the range of contiguous data blocks, which can be useful for certain specialized use cases, such as supported Shingled Drives.

вот так

e4defrag -c /dev/sdXX

Убери -c, нафиг ты его ставишь?

нафиг ты его ставишь

не поставишь начнется дефрагментация, а зачем это надо если не нужно?

Так чего спрашивал тогда-то?

Да, но эффективно ли?

С т.з. скорости наверное да. А вот с т.з. надёжности наверное нет.

я спрашивал в чем подвох при дефрагментации с помощью e4defrag и получил ответ, что он только хуже делает, не знаю так это или нет, но приму к сведению...

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

Кто тебе такое сказал?

а подвох стандартен - если во время дефрагментации будут...

Он же ничего не дефрагментирует на самом деле, а тупо создаёт новый файл в надежде, что он будет удачнее расположен чем старый, и переписывает туда содержимое.

Кто тебе такое сказал?

ты https://www.linux.org.ru/forum/general/15271657?cid=15271723 (комментарий)

А пруф у этого анона есть?