EXT4 для очень больших (>1 ГБ) файлов: увеличить размер блока, использовать блоковые кластеры или и то, и другое?

Я хотел бы отформатировать HDD емкостью 12 ТБ (не SSD) с файловой системой EXT4, чтобы хранить большие видеофайлы (каждый файл размером не менее 1 ГиБ).

Я работаю с процессором x86-64 (также известным как x64 или amd64).

Существует, конечно, опция -T largefile4 у mkfs.ext4, но есть ли другие оптимизации, которые можно сделать?

В частности, я хочу знать:

• Стоит ли увеличить размер блока до максимального (64K, -b 65536)?
• ИЛИ стоит использовать кластерные блоки и установить размер кластера на максимальный (256M, -C 268 435 456)?
• ИЛИ следует сделать и то, и другое?

Какие параметры будут лучшими с точки зрения использования дискового пространства и оптимизации производительности?

В документе, на который вы ссылаетесь, говорится (выделение мое):

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

Из хорошо известных архитектур процессоров, способных запускать Linux, только ARM, Alpha AXP, Itanium или PowerPC имели возможность использовать размеры страниц более привычных 4 KiB.

Хотя процессоры AMD64/x86_64 могут использовать огромные страницы, это не совсем одно и то же – базовый размер страницы системы по-прежнему составляет 4 KiB, огромные страницы просто позволяют выделять их более крупными пакетами для повышения эффективности управления памятью в системах с большим объемом памяти. Это не изменяет основное требование “размер блока ext4 <= размер страницы системной памяти”.

С процессорами PowerPC или 64-битными ARM размер страницы (базовый “размер блока” управления системной памятью) может быть увеличен до 64 KiB, что позволяет файловой системе ext4 также масштабировать свои внутренние операции. На AMD64/x86_64 эта опция недоступна, поэтому кластерные блоки будут единственным доступным способом уменьшить пространство и рабочие затраты, необходимые для метаданных файловой системы.

Я использовал систему с файловой системой ext4, расширенной до диапазона более 10 ТБ, и проведение проверки файловой системы на ней было не самым приятным опытом. Следует отметить, что это была старая система, чьи файловые системы были расширены и повторно расширены без какого-либо тщательного настройки, далеко за пределы первоначальной проектной мощности системы. (Это также был видеосервер.)

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

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

EXT4 может обрабатывать файлы размером до 16TiB и файловые системы размером до 1PiB достаточно хорошо, и она регулярно используется в таких размерах в некоторых из крупнейших параллельных файловых систем мира (см. https://en.wikipedia.org/wiki/Lustre_(file_system) для подробностей). Не должно быть никаких проблем с файлами размером 1GiB и HDD емкостью 12 TiB.

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

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

Дополняя ответ TelcoM… если вы хотите использовать размер блока, отличный от 4Kb на x86[-64], тогда вам нужно будет перекомпилировать ядро. Это раньше был единственный способ поддерживать большие файловые системы с 32-битными ядрами. Но затем появилась поддержка больших файлов и 64-битные иноды. И в наши дни (если вы все еще не работаете на 32-битной системе) вам даже не нужно сообщать mount/fstab, что файловая система использует 64 бита. Но все равно в интернете есть много устаревшей информации (например, в текущей документации aws – https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/volume_constraints.html).

Кластерные блоки в ext4 предоставили обходной путь для 32-битных инодов / 4k размера блока.

Но это уже не имеет отношения – 32-битные иноды + 4K размеры блока ограничивали общий размер блочного устройства до 16Tb, а у вас всего 12.

Существуют причины для использования блоков (или кластеров блоков) разного размера. Если я правильно помню, как Oracle, так и MySQL используют внутренний размер блока 8k – и соответствие этому в файловой системе дает значительное увеличение пропускной способности.

Итак… нет, вам не нужно делать ничего хитроумного (кроме использования GPT вместо MBR, если вы делите разделы).

EXT4 действительно позволит вам использовать только блоки, соответствующие размеру страницы (4K на x86_64), и я бы рекомендовал оставить его на 4K по соображениям совместимости.

Опции largefile и largefile4 снижают соотношение инодов к пространству, так что вы тратите меньше места на них, но они не действительно оптимизируют сверх этого.

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

Я использую это для своего тома хранения QEMU VM:

mkfs.ext4 -O bigalloc -C 2097152 -n /dev/blockdevice

Это создаёт кластеры блоков по 2 МБ (4K * 512). Мне нравится 2 МБ, потому что большая страница на x86_64 – 2 МБ, так что если кэш страниц когда-либо будет преобразован для использования больших страниц, это должно позволить файловой системе выровняться и поместить один кластер блока в одну большую страницу.

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

Наконец, думаю, что на 2 МБ вместо 4K вы уже находитесь на 1/512 от накладных расходов для этого аспекта файловой системы, и я думаю, что здесь есть закономерная тенденция к уменьшению отдачи, если только у вас нет поистине гигантских томов класса петабайт.