Подбор размера блока файловой системы под базу данных и под крупные медиафайлы

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

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

Что такое блок и почему его размер влияет на всё

Блок это минимальная единица, которой файловая система выделяет место под данные. Любой файл, каким бы крошечным он ни был, занимает целое число блоков, и пустой остаток последнего блока пропадает впустую. Если блок крупный, а файл мелкий, потери на этих хвостах накапливаются и съедают ощутимую долю ёмкости. Это явление называют внутренней фрагментацией, и оно тем заметнее, чем больше блок относительно типичного файла.

С другой стороны, чем крупнее блок, тем меньше их нужно для хранения большого файла и тем меньше служебных записей о расположении этих блоков. Крупный блок позволяет читать и писать большими порциями за одно обращение, что разгоняет работу с объёмными файлами и снижает накладные расходы на учёт. Получается классический компромисс: мелкий блок экономит место на россыпи маленьких файлов, крупный блок ускоряет работу с большими.

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

Как форматировать с явным указанием размера блока

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

sudo mkfs.ext4 -b 4096 /dev/sdb1

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

sudo mkfs.ext4 -b 4096 -L media-storage /dev/sdb1

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

sudo mkfs.xfs -b size=4096 /dev/sdb1

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

Почему база данных любит блоки помельче

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

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

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

Почему крупные медиафайлы требуют блоков покрупнее

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

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

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

Как сопоставить размер блока с физическим устройством

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

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

sudo blockdev --getpbsz --getss /dev/sdb

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

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

Что ещё настраивают вместе с размером блока

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

sudo mkfs.ext4 -b 4096 -i 1048576 /dev/sdb1

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

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

Чем грозит неудачный выбор размера блока

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

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

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

Краткий ориентир по выбору

Чтобы решение не превращалось в гадание, удобно держать перед глазами короткую логику подбора:

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

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

Что в итоге запомнить

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

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