Комментарии 22
Напомнило, еще лет 20 на XFS наталкивался на пренеприятнейшую фичу, ибо багом они ее не признавали тогда, что если место забивается, попытка открыть любой файл на запись, приводила к его нулению. Не помню точно, но наталкивался на объяснение что типа это для вашей безопасности и т.д., потом вроде признали, но похоже болячек там пруд пруди еще
Вроде как XFS для СУБД избыточна, Ext3/4 достаточно.
Там чем проще ФС, тем лучше, ну разве что журналирование метаданных полезно.
На больших размерах БД очень даже не избыточна, а весьма полезна. Большие файлы индексов, wal файлы и сами таблицы скажут вам спасибо. Особенно при частых UPDATE/DELETE.
Следом идут блоки до 64 КБ, чтобы удобно работать с восьмикилобайтными страницами постгреса. И не забываем про многопоточку и раздельную работу с журналами метаданных.
Так что XFS это дефолтная опция в энтерпрайзах.
у ext3/4 то же есть аж пепперы , где не все так радужно было. Наверно можно так же , что то свежие найти
Сталкивался с глючащим железом на сервере, выглядело это страшно. Причем постгрес падение по сегфолту и дальнейший перезапуск переносит относительно спокойно, а в elasticsearch это каждый раз заканчивалось повреждением индекса, чинить который очень тяжело и проще грохнуть и заново создавать.
Все бы хорошо, но следовало бы написать на каком дистрибутиве Linux и с какой версией ядра Вы воспроизводили проблему, прям таблично.
Если не ошибаюсь, у Oracle Linux применена куча дополнительных патчей на ядро (UEK ядра linux) именно для XFS и даже если там предполагается что ядро с багом, то не факт что он есть на самом деле именно в Oracle Linux. То же касается и RedHat.
Все условия необходимые для воспроизведения бага подробно описаны.
Исходники софта для проверки тоже.
Очевидно что сидеть и проверять каждую версию ядра, в каждом дистрибутиве мы не можем т.к. это займёт околобесконечное количество времени. Проведите эксперимент на доступных вам системах, поделитесь результатами и все скажут вам спасибо.
Любопытно, что подсистема ядра, в которой описываемый баг был обнаружен, как раз Ораклом разработана.
XFS разработал Silicon Graphics, к Oracle она имеет отношение только как дефолтная ФС используемая в Oracle Linux.
Я думаю, имелось в виду init on free и/или фолианты. Могу ошибаться.
Как минимум, и коммит, породивший проблему, и коммит, починивший проблему, сделаны одним и тем же человеком - разработчиком из Oracle - с разницей в два года.
Конечно, может быть эти его изменения были протолкнуты в основное ядро, и при этом в самом Oracle каким-то образом проблемы не приносили. Но, согласитесь, это будет неожиданно и странно.
Смотрим версию ядра красной шапки:
9- 5.14, все что ниже соответственно ниже, 10 - 6.12, соответственно все что на нём основано не подходит под условия, расходимся.
Именно! Этот факт мы тоже заметили и долго улыбались, что красная шапка что-то явно знает что не знаю другие, включая российские компании распространяющие Linux.
RH включает "потенциально баговый" патч в 5.14.0-130.el9, а потенциальный фикс в 5.14.0-611.16.1.el9_7 пока не включила.
С другой стороны, в RH init_on_free по умолчанию выключен - но что-то мне подсказывает, что не XFS единым...
Смотрим версию ядра красной шапки:
9- 5.14, все что ниже соответственно ниже, 10 - 6.12
Эти номера версий имеют мало общего с реальным кодом, и "5.14" включает в себя чуть ли не половину "бэкпортированного" 6.12. В этих франкенядрах без исходников делать особенно нечего.
Сейчас безопасники меня съедят, но init_on_free и init_on_alloc - зло!
И перф кушают, и такие приколюхи дают :)
Будто страшную сказку на ночь прочитал.
История поиска бага в ядре Linux длиной в год, или нежданные нули из XFS'а