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

ну так и спроси его как анон анона!

неужто такой прымитив.

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

но в линуксе фрагментации не существует :)

но в линуксе фрагментации не существует :)

Не хорош ли по одним и тем же граблям то гулять? Логика размещения файлов в ФС (комментарий)

он только хуже делает

Не то. Не хуже делает, но и «лучше» (а точнее «менее плохо») это тоже не назовёшь.

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

не меньшая проблема

Именно меньшая и намного меньшая!

Херня. Иноды закешировать проще чем данные, тк они меньше весят.

Иноды закешировать проще чем данные

Только их сначала «прочитать» надо. Логика размещения файлов в ФС (комментарий)

обратная ситуация: один файл, но напиленный фрагментами по самое небалуйся. инод один но длинный и сильно нафаршированный.

инод один но длинный и сильно нафаршированный.

Сам прочитал написанное? А я о чём собстна говорю? Алё?

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

Пруфец будет?

Не вникал в методику размещения, не нужно было. За подробностями придётся лазить в код.

Мы тут с помощью твоей тулзы уже всё выяснили)

Что за диагональные просветы в 1-2 клетки?

Ext4 делит всё дисковое пространство на группы блоков. В каждой группе в начале находятся таблицы inode. В ext4 число инодов фиксировано и задаётся во время форматирования. Вот там в начале групп эти таблицы и лежат. Это место нельзя отобрать у инодов и использовать под хранение данных, поэтому оно всегда будет просветами на карте. На карте показываются только блоки, занятые файлами и директориями.

инод один но длинный и сильно нафаршированный.

Inode это структура фиксированного размера. Её нельзя поменять в процессе работы штатными способами. В ней есть 60 байт места, где либо хранится список блоков, составляющих файл, либо перечисляются диапазоны блоков (extents), где лежит файл. Если файл маленький, он может прямо в этих 60 байтах храниться.

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

У более традиционных ФС файлы заполняют логически связанные цепочки блоков ФС, геометрически (адресно) расположенных рядом (последовательно) на незаполненном данными других файлов пространстве или на пространстве удалённых ранее файлов. Запись выполняется согласно алгоритму последовательного чтения - «лифта» (или элеватора - забрать со всех мимо проезжаемых этажей пассажиров за один проезд вниз или вверх, смотря на какой этаж им требуется, и доставить их программе в правильно собранном виде, как и запрашивалось). Это делается с целью минимизации перепозиционирования считывающей головки винчестера при считывании логически связанных цепочек блоков с данными файла. Так как операций чтения, как правило, больше операций записи, оптимизация размещения данных должна быть проведена обязательно.

В UFS2 данные файла локализуются в определённой группе блоков или в смежных группах блоков. Групп блоков на слайсе (партиции, разделе, томе диска) может быть десятки и повреждения в одной или нескольких смежных группах приводят лишь к потерям соответствующих файлов, данные которых находятся в них.

$MFT уменьшается в размере при недостатке места на диске. А так, на свежеформатированном разделе он довольно много места занимает.

Отложенного распределения

Чтобы был пушистый зверек при внезапном отключении. sync еще не приучился в консоли вбивать на всякий случай? У винды API дефрагментатора транзакционный.

Отложенного распределения

Чтобы был пушистый зверек при внезапном отключении.

Ext4 решает, где будет лежать файл непосредственно перед записью данных из write-back кеша. NTFS решает сразу же, как только данные попадают в write-back кеш. Если питание внезапно пропадает до того, как происходит запись непосредственно данных, они будут утеряны и у ext4, и у NTFS. Отсутствие отложенного распределения не помогает в деле сохранности данных. Зато оно помогает предотвращать фрагментацию.

У XFS правила размещения данных таковы:

1. Вся ФС делится на какое-то количество (дефолтно 4) Allocation groups (AG). Каждая AG имеет своё собственное дерево inode'ов, поток обслуживающий чтение/запись inode'ов и т.п. Поэтому они как «разделы» в ФС.

2. Планированием записи данных и inode'ов на AG руководит allocator. Раньше их было более одного, сейчас вроде повыпиливали все кроме дефолтного. У дефолтного allocator'а очень простое, но при этом эффетивное поведение — директории по возможности создаются в разных AG (для распараллеливания доступа к ним), а файлы, лежащие в одной директории — в одной AG и при той же, что и директория, в которой лежат файлы.

3. XFS хранит для каждой AG два B-дерева. В каждом хранится информация об экстентах — группах блоков без данных (кусках свободного места, если проще). Одно B-дерево индексировано по размеру эксентов (чтобы можно было подобрать кусок подходщий по размеру файлу который записывается), а другое индексировано по первому блоку каждого экстента (соответственно понятно в каком порядке они идут на HDD).

4. Описание алгоритма выбора экстентов для записи файлов я не встречал («надо смотреть код»). Подозреваю, что он берёт за основу информацию из B-деревьев, текущую нагрузку и т.п., ну и пытается максимально эффективно распределить файлы внутри AG.

5. Размер минимального блока записи зависит от настроек создания ФС. Уже достаточно давно XFS умеет определять при создании оптимальный размер блока основываясь на параметрах RAID'а и/или диска на котором её создают.

6. У XFS есть достаточно хитрый алгоритм speculative preallocation (если честно, до сих пор не знаю как это переводится на русский). Если кратко, то это алгоритм «бронирования» места под будущее разростание файла. Соответственно некоторое пространство после файла закрепляется за ним на какое-то время (дефолтно 5 минут), а потом возвращается в «пул» доступных экстентов.

7. Ну и если так уж получилось, что файл записался не одним куском, то есть дефрагментатор xfs_fsr, который умеет, собирать фрагментированнные файлы (если файл не больше, чем объём свободного места в ФС).

По какой логике заполняются файлами линуксовые ФС вроде ext4 и xfs — по порядку, от начала раздела к концу, или данные могут писаться куда угодно, хоть в начало, хоть в конец, хоть в середину?

https://opensource.com/article/17/5/introduction-ext4-filesystem

В чём смысл вопроса? Тебе лень гуглить и читать, об этом хотел сообщить? Или тебя интересует что-то конкретное?

Благодарю, основательная инфа

В магазине Ubuntu прям продавался дефрагментатор гуёвый HDD Ranger за порядка $10

http://ubuntued.info/wp-content/uploads/2013/07/hdd-ranger-main.png.jpg

Но магазин этот накрылся медным тазом давно уже.

Спасибо!