Выбор Ext4 или xfs под базу данных. Посоветуйте

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

Здесь работает аксиома Эскобара.

состоящая из ~ 2200 файлов в 60 каталогах

Любая фс.

фс под базу данных.

Нормальную реляционную БД в зависимости от проекта.

предпочтительнее настроить UPS.

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

Существует мнение, что нормальные БД используют fsync/fdatasync и журналы для обеспечения подтвержденной записи когда работают с файлами на ФС, и иногда даже пишут с O_DIRECT (но нечасто, надо признать), а нормальные сервера стоят на UPS, которые продержит их минимум 15 минут.

Так дело вовсе не в том, что она сыпется. Производительность падает. Лучше всего конечно в raw писать.

Лучше найти рекомендации от производителя БД или того кто оказывает его коммерческую поддержку, например DataStax для Кассандры рекомендует XFS или Ext4 http://docs.datastax.com/en/landing_page/doc/landing_page/planning/planningHa...

Производитель БД вообще не говорит про файловые системы в Linux...

ну ты бы хоть БД конкретизировал или ждёшь штатных телепатов? также есть разница соотношения чтения и записи

БД - Pervasive 11

XFS очень старая хрень с непонятными преимуществами. Единственная ФС на моей памяти, где после обычной перезагрузки можно обнаружить, что у тебя просто исчезла пара каталогов.

XFS очень старая хрень с непонятными преимуществами.

В линуксе активнее разве что Btrfs разрабатывается. Старая хрень это ext4, на которую RedHat начал забивать.

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

Любитель монтировать с nobarrier?

В линуксе активнее разве что Btrfs разрабатывается.

В чём понт btrfs при отключенном COW?

Старая хрень это ext4,

Это называется «entrprise-ready»

на которую RedHat начал забивать.

Тлетвоное влияние Лёни xD

В чём понт btrfs при отключенном COW?

Но зачем?

Это называется «entrprise-ready»

Окей.

Тлетвоное влияние Лёни xD

Они продвигают XFS, а не Btrfs.

Но зачем?

Во-во

Они продвигают XFS, а не Btrfs.

Спаси господи! (С)

и правильно делает, про них лучше вообще не говорить.

В чём понт btrfs при отключенном COW?

В том, что COW имеет смысл отключать далеко не для всех применений. А точнее, только для одного, который описывается как «множественная случайная запись мелкими фрагментами в большой файл». И даже с отключенным COW можно делать снапшоты, откатываться назад и т.д.

P.S.: если бы в ext4 был функционал CLONE_RANGE, хрен бы я на BTRFS посмотрел.

ext4 под «монолитными» БД (типа, одна таблица = один файл) работает немного шустрее, чем xfs. Других концептуальных различий под этой задачей нет, так что я ставлю обычно ext4.

Вот если под БД подразумевается собственное хранилище, то зависит от типа и условий. Если 2200 файлов в 60 каталогах, то разница, скорее всего, будет на уровне погрешностей. Вот если будет 220000 в 600 каталогах и всё это под активным параллельным чтением и тебуется регулярно обходить каталоги (rsync/find-очистка/...), то тут ext4 почти ложится, xfs просто тормозит, а палочкой-выручалочкой остаётся reiserfs.

В чём понт btrfs при отключенном COW?

1. хранилища на нескольких дисках (в том числе разного размера) с возможностью добавлять/убирать по одному

2. raid-образная избыточность

3. контрольные суммы

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

Никогда такого не слышал. Лет 10 назад, при жёстком выключении при падении питания без БП можно было словить (и я ловил не раз) зануление (забитие нулями) некоторых открытых в момент падения файлов. При чём это был не баг, а фича, система такое делала из соображений безопасности, чтобы тебе в файлы не попали чужие данные из-за сбоев. Но потом такое поведение исправили и я уже лет 8, как не слышал про подобное (как и не натыкался).

Вот с чем регулярно сталкиваюсь и на ext4, и на xfs — это редкие повреждения данных в файлах на больших объёмах. Что-то порядка нескольких сбоев (3-6) на 2Тб данных за месяц-два. Хорошо видно на раздачах торрентов — они ловят такое.

Ещё на ext4 нарывался пару раз на повреждение посторонних файлов при переполнении раздела.

reiserfs при работе в loop-образе в конце прошлого года стала вешать иногда всю дисковую подсистему. Я долго не мог понять причин.

Больше в последнее время проблем с ФС не было :) Вот раньше — да. ext3 однажды умерла целиком просто при нормальной работе сервера. На ext4 случались пропажи каталогов при вырубании питания. Из всех систем, с которыми работал, при аварийных ситуациях данные не пропадали только на reiserfs (был как-то адский период, когда сервер в течении пары месяцев приходилось ресетить почти каждый день, а иногда и дважды в день — и выжила, ни одной потери! :D) и ntfs.

Тут ключевой момент в способе работы fs. Ext4 сохраняет данные раз в 5 секунд, xfs регулярно не сохраняет, у нее по другому работает буфер. Если вы хотите надежности - ext4, если у вас большие данные и нужна скороть и есть бэкап - xfs

Контрольные суммы при отключении CoW отвалятся. Поэтому я никогда её не отключаю, даже если апстрим рекомендует (в systemd поставляется конфиг, отключающий CoW на /var/log/journal/).

1. хранилища на нескольких дисках (в том числе разного размера) с возможностью добавлять/убирать по одному

Надеюсь, речь не про встроенный RAID?

2. raid-образная избыточность

Нууу. ладно.

3. контрольные суммы

Оно работает всё лучше и лучше.
Но «для десктопа не готов»(С)

Вот с чем регулярно сталкиваюсь и на ext4, и на xfs — это редкие повреждения данных в файлах на больших объёмах. Что-то порядка нескольких сбоев (3-6) на 2Тб данных за месяц-два. Хорошо видно на раздачах торрентов — они ловят такое.

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

В том, что COW имеет смысл отключать далеко не для всех применений.

Речь про СУБД

И даже с отключенным COW можно делать снапшоты, откатываться назад и т.д.

Так, да. Снапшоты у меня даже работали.

Память проверь

Это многолетняя эпопея на LOR и Juick — было несколько крупных тем :) На разных машинах, разных версиях Linux (Gentoo, Ubuntu). И на старой машине уже ничего от старого железа не осталось — и платформа другая (память/проц/мать) и винты другие... Долго под подозрением был LVM, но недавно ошибку в фотоархиве (~600Гб) словил на внешнем сервере без LVM.

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

Никакой мистики, это обычная статистика сбоев при чтении. Вот статистика ошибок в данных CERN, она примерно соответствует тому, на что натыкаюсь я :) — Сканер изменений в содержимом файлов, атрибуты которых не менялись. (комментарий)

Просто сбой байта на гигабайт в год многие не замечают. А я стал на это обращать внимание, когда стали попадаться битые фотки в большом семейном фотоархиве (сейчас ~100 тыс. фото на 600Гб за 15+ лет).

и я уже лет 8, как не слышал про подобное (как и не натыкался).

Около пяти лет назад просто исчезла половина NoSQL БД после обычной перезагрузки сервера. Там на винтах из ~120Гб было свободно 1-2Гб, после перезагрузки стало ~50Гб свободного места, но никто на это внимание не обратил, пока не пошли звонки клиентов :)

Если вы хотите надежности - ext4, если у вас большие данные и нужна скороть и есть бэкап - xfs

Большие данные для xfs, размер файла какого порядка? Файл не изменяется (фильмы, образы) или изменяется (БД)?

Ну по описаниям xfs работает хорошо с большими файлами(операции с ними, чтение запись и т.д.) Большие это наверное несколько гиг

Ну по описаниям xfs работает хорошо с большими файлами(операции с ними, чтение запись и т.д.) Большие это наверное несколько гиг

Больше мегабайта. Просто эти легенды берут начало в ОЧЕНЬ далёких временах.

Мораль - тебе нужна файловая система с проверкой CRC как минимум (а как максимум - с избыточностью). И поскольку фотоархив (да и любой файлохранилищный ресурс) в общем-то работает по принципу «записали файл, потом он лежит», то тебе нужна, внезапно, BTRFS, тем более что перезаписей файлов у тебя в общем то и не случается - так что даже nodatacow делать не надо, а значит crc заработает :-)

Хорошо видно на раздачах торрентов — они ловят такое.

А какой клиент это ловит? Или ты вручную проверку запускаешь?

Несколько лет с одного терабайтного внешнего HDD раздавал и не натыкался ни разу. ФС ext4

Мораль - тебе нужна файловая система с проверкой CRC как минимум

Да. Но вменяемых систем таких пока нет. Даже ZFS, хотя её активно советуют по этому вопросу, пока не оптимальна :)

то тебе нужна, внезапно, BTRFS

Ну-ну :)

Хорошо видно на раздачах торрентов — они ловят такое.

А какой клиент это ловит?

Разве, не любой? Торрент при раздаче отдаёт блоки с проверкой CRC. Поэтому сбой в блоке должен сразу ловиться.

По крайней мере Transmission такое ловит. Изредка (порядок величины раз в месяц на 2Тб данных и 600 раздач) раздачи останавливаются «ошибка в блоке таком-то». Запускаешь раздачу принудительно, оно начинает докачивать 0.01% (типа, один блок).

Несколько лет с одного терабайтного внешнего HDD раздавал и не натыкался ни разу. ФС ext4

Значит, либо клиент не проверяет, либо автоматом исправляет/докачивает, либо история тут (у меня, галантерейщика^W кардинала^W, CERN и ещё ряда отозвавшихся лоровцев/жуйковцев) ещё более сложная :)

я бы спросил у системного администратора

Значит, либо клиент не проверяет, либо автоматом исправляет/докачивает, либо история тут (у меня, галантерейщика^W кардинала^W, CERN и ещё ряда отозвавшихся лоровцев/жуйковцев) ещё более сложная :)

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

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

В общем если файлопомойка предполагается большая лучше xfs, у нее иноды динамические и вообще она больше приспособлена для такого

В общем если файлопомойка предполагается большая лучше xfs, у нее иноды динамические

Кстати, да. Сколько раз мне ext4 этим жизнь портила. Заранее не рассчитаешь — всё, в один прекрасный момент раздел заполнен на половину, а писать уже нельзя... И на лету не поменять. Хорошо, когда LVM есть с резервом места. А когда нет — песец. Хоть loop-образ поднимай :) (и в некоторых случаях так даже быстрее работало! — пока reisrefs в loop не стал систему вешать :D)

Я тоже читал про глюкодром, но чем заменить? Мне достаточно режима «две копии всего на разных дисках».

Любитель монтировать с nobarrier?

Всегда всё оставляю по умолчанию, ну кроме noatime и discard для SSD.

Я тоже читал про глюкодром, но чем заменить?

Из того, что в ядре - нечем.

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