Не все файловые системы Linux обладают одинаковыми характеристиками. Поэтому вам следует выбрать файловую систему, подходящую для характера вашей работы. Если вы примете неверное решение, у вас могут возникнуть проблемы во время использования.
Детали выбора файловой системы, обычно возникают один раз — во время процесса установки операционной системы — и редко пересматриваются впоследствии.
Основная проблема
Файловые системы, поставляемые с RHEL 9.7 и Ubuntu 24.04.4 LTS, включают настройки по умолчанию, оптимизированные для рабочих нагрузок общего назначения, а не для ваших уникальных моделей работы. Использование ext4 для серверов баз данных, использование XFS для агрегации журналов без учета ограничений инодов и использование Btrfs RAID 5/6 в производственных средах без аппаратной защиты от записи — это конфигурации, которые, вероятно, незаметно выйдут из строя при масштабировании. Цена этого — не обязательно снижение производительности, может быть и серьезнее – недоступность данных.
Сравнение файловых систем Linux: ext4, XFS и Btrfs
Важнее, чем узнать, какими функциями обладает каждая файловая система, — это понять замысел, лежащий в основе каждой файловой системы, поскольку именно это предсказуемо укажет, как каждая файловая система будет вести себя под нагрузкой. Файловая система, которая в изоляции показывает хорошую производительность в тесте fio, не будет вести себя иначе, чем другая файловая система, выходящая из строя под нагрузкой потокового шквала записей PostgreSQL, происходящего в 3 часа ночи.
ext4 — проверенная универсальная файловая система по умолчанию
ext4 является прямым потомком ext2 и ext3 и, следовательно, унаследовала как их сильные, так и слабые стороны. В ext4 таблица инодов создается во время mkfs и занимает фиксированный процент от общего объема тома (один инод на каждые 16 КБ пространства). Таким образом, на томе объемом 2 ТБ, созданном с настройками по умолчанию, будет примерно 131 млн inode. Для работ, генерирующих файлы среднего размера от 4 до 8 КБ (логические отправщики, почтовые очереди, уровни каталогов для образов контейнеров), запас инодов будет исчерпан задолго до достижения пределов емкости дискового пространства.
Помимо лучшего набора инструментов ведения журнала и fsck (e2fsck), ext4 также обладает одними из самых отлаженных механизмов восстановления, которые являются в высшей степени предсказуемыми и понятными практически каждому специалисту по эксплуатации и восстановлению (SRE) в Linux. Одна из областей, в которой ext4 превосходит другие системы, — это ограничение максимального размера файлов до 16 ТБ (очень актуальное ограничение для многих серверов NFS, хранящих дампы баз данных, приближающиеся к этому пределу; в этой области XFS работает без необходимости настройки).
XFS — производственный стандарт с высокой пропускной способностью
XFS изначально был разработан в Silicon Graphics для поддержки серверов с высокой пропускной способностью, а затем в 2001 году был передан в распоряжение ядра Linux. С 2014 года (года, когда RedHat выбрала XFS в качестве файловой системы по умолчанию для RHEL 7) и вплоть до RHEL 9.7 (релиз 12 ноября 2025 года) RedHat поддерживает XFS в качестве предпочтительной файловой системы из-за одного основного архитектурного отличия, которое существенно влияет на его работы: XFS не выделяет иноды во время форматирования. В результате исчерпания инодов в XFS не происходит. Кроме того, XFS поддерживает файлы размером до 16EiB, что более чем в тысячу раз превышает максимальный размер файла, допустимый в ext4.
Однако у XFS есть одно структурное ограничение, которое не скроет ни один тест производительности. Файловые системы XFS могут только увеличиваться; они никогда не могут уменьшаться. Поэтому планируйте размер тома достаточно большим, чтобы он соответствовал вашим потребностям с учетом ожидаемого использования. В настоящее время нет механизма, позволяющего уменьшить том XFS после его создания. Планируется добавить эту возможность в будущих выпусках. На сегодняшний день дата выпуска с такой функцией не запланирована. Ядро Linux 7.0 было выпущено в марте 2026 года. Одной из функций, добавленных в XFS в этом выпуске ядра, стала функция автономного самовосстановления. Это означает, что если XFS обнаруживает поврежденные метаданные, он может исправить эту проблему автоматически, без необходимости размонтировать файловую систему. Это устраняет основную причину выбора Btrfs вместо XFS в случаях, когда важна проверка целостности данных. Таким образом, пользователям RHEL, не нужно идти на компромисс между чистой производительностью и проверкой целостности данных.
Btrfs — с встроенной поддержкой моментальных снимков
Основные причины, по которым Btrfs превосходит две другие файловые системы в плане надежности, включают:
- Встроенные возможности создания моментальных снимков.
- Контрольные суммы данных и метаданных.
- Архитектура «копирование при записи».
Благодаря этим характеристикам создание нескольких моментальных снимков аварийного восстановления практически не требует дополнительных затрат места. SLES 15 SP6 также использует Btrfs в качестве файловой системы по умолчанию. С другой стороны, RHEL 9.7 и Ubuntu 24.04.4 LTS по-прежнему не поддерживают Btrfs в качестве файловой системы.
Red Hat полностью удалила Btrfs как вариант в RHEL с выпуском RHEL 8 и решила не возвращать его в RHEL.
При работе с базами данных операция «копирование при записи» создает дополнительную нагрузку. Это происходит всякий раз, когда движок Базы данных записывает данные в блок на диске. Затем Btrfs записывает обновленный блок в другую область диска, обновляет дерево метаданных, отражая это изменение, и спустя некоторое время удаляет старую версию этого блока. Тесты PostgreSQL и Mysql обычно показывают, что при аналогичных нагрузках Btrfs теряет от 10% до 25% пропускной способности записи по сравнению с эквивалентной конфигурацией XFS.
Параметр Btrfs compress=zstd может помочь компенсировать затраты на хранение для приложений, которые в основном полагаются на ведение журналов, и может снизить накладные расходы COW, связанные с операциями произвольной записи. Однако ни один из параметров не устраняет накладные расходы COW при выполнении операций произвольной записи.
Что на самом деле означают цифры тестов
В августе 2024 года исследователи из Университета Джорджа Мейсона провели исследование поведения файловых систем в масштабе (один миллиард файлов) и опубликовали свои результаты на arXiv. Их выводы показывают, что только XFS обеспечивал надежный доступ к тестовым данным без перенастройки во время экспериментов. Btrfs не смог успешно завершить тест в режиме «только для чтения», а ext4 потребовал перестроения таблицы инодов перед завершением теста.
Это задокументированное поведение этих файловых систем, демонстрирующее, что произойдет, когда оркестратор накопит многолетние наслоенные образы, не очищая их регулярно.
Средства контроля целостности данных
| Файловая система | Контрольная сумма метаданных | Контрольная сумма данных | Обнаружение скрытого повреждения | Аудиторские доказательства |
|---|---|---|---|---|
| ext4 | Журнал | Нет | Нет | Только журналы fsck |
| XFS | CRC32c | Нет | Только метаданные | журналы xfs_repair; события самовосстановления ядра 7.0 |
| Btrfs | CRC32c / SHA-256 | Да — для каждого блока | Да — данные метаданные | Отчеты btrfs scrub; события журнала systemd |
Для производственных сред, которым требуются проверку целостности данных (особенно SOC 2 CC6.1 и NIST SC-28), Btrfs предоставит наиболее прямой аудиторский след на уровне файловой системы через журналы отчетов btrfs scrub. XFS с ядром Linux 7.0 самостоятельно восстанавливается и генерирует записи в журнале ядра, которые могут быть зафиксированы системой SIEM, однако это сосредоточено на целостности метаданных, а не на контрольных суммах данных на уровне блоков. ext4 имеет наименьший объем доказательств целостности при аудите; если вы планируете использовать ext4 в качестве файловой системы, а ваша программа обеспечения соответствия требует возможности аудита ext4, вам необходимо реализовать аудит либо на уровне приложения, либо на уровне менеджера томов.
Заключение
Выбирайте правильную файловую систему до первой записи, а не после первого инцидента.
При обсуждении сравнения файловых систем ext4/xfs/btrfs в 2026 году нет споров о том, является ли XFS технически лучше, чем ext4 или btrfs — есть только задача выбора предстоящих нагрузок с реальными последствиями для продакшена. Таким образом, XFS является правильным выбором для серверов баз данных, хранилищ с высокой пропускной способностью и рабочих нагрузок с большими файлами.
Результаты тестирования, а также исследование Университета Джорджа Мейсона с миллиардом файлов указывают на одно и то же. ext4 по-прежнему подходит для файловых сервисов общего назначения, но требует настройки инодов при форматировании любой файловой системы, используемой для создания большого количества небольших файлов. Btrfs заслуживает своего места в качестве целевой системы для резервного копирования, файловых систем с большим количеством снимков и файловых систем, чувствительных к вопросам соответствия требованиям, благодаря тому, что btrfs предлагает контрольные суммы на уровне блоков, обеспечивающие готовые к аудиту доказательства целостности — однако RAID 5/6 на btrfs в 2026 году НЕ будет готов к использованию, если не будет подкреплен аппаратной защитой от записи.
Поэтому первым шагом будет проверка всех производственных томов, в настоящее время использующих файловую систему, не соответствующую их предполагаемому сценарию использования. Начните с томов ext4 на серверах сбора журналов — запустите df -i на каждом из них и отметьте все файловые системы ext4, показывающие использование инодов более 50%, для переформатирования или перемещения. После этого определите, какие из ваших томов XFS находятся в средах LVM, где обсуждался вопрос о возврате ресурсов при тонком выделении — зафиксируйте ограничение «без сжатия» до того, как событие, связанное с емкостью, приведет к переходу в аварийный режим.
Для ИТ-отделов, поддерживающих операции резервного копирования в Linux, обсуждаются рабочие процессы с использованием собственных моментальных снимков Btrfs, а также другие традиционные методы резервного копирования серверов. Кроме того, в руководстве описывается, как создавать политики хранения, запрещающие незаметное увеличение объемов резервных копий за счет снимков.
Что касается того, что указывает дорожная карта разработки, то она, похоже, отдаёт предпочтение XFS. С введением автономного самовосстановления в ядре Linux 7.0 одна из немногих оставшихся причин выбора Btrfs вместо XFS исключительно на основе целостности инфраструктуры на базе RHEL. Единственный крупнейший неизвестный фактор, связанный с выходом Btrfs Raid 5/6 из экспериментальной стадии в ядре 7.x, представляет собой наиболее критическую открытую проблему, стоящую перед горизонтом планирования на 2026–2027 годы — разработчики Btrfs заявили, что продолжают работать над этим проектом, но конкретные сроки не установлены.
Комментарии (0)