Вот статья на lwn.net, в которой обсуждается потенциальная потеря данных, когда программе не удается выполнить адекватную синхронизацию (также известную как отказоустойчивость) на ext4 в длину (обсуждение комментариев также полезно).
ext3, по-видимому, обеспечивает лучшую согласованность при сбое при использовании data=ordered, потому что данные передаются на диск до того, как изменения метаданных фиксируются в журнале.Кроме того, период фиксации по умолчанию составляет 5 секунд.В случае ext4 достигается компромисс между производительностью и использованием модели с отложенным распределением физических блоков, что приводит к тому, что незафиксированные данные еще некоторое время остаются в кеше.Цитата из статьи:
Ядро не хочет, чтобы данные файла оставались незаписанными слишком долго, но это может занять около минуты (с настройками по умолчанию), чтобы эти данныесбрасывать - намного дольше, чем пять секунд, обычно наблюдаемых с ext3
Таким образом, неписанные данные теоретически могут существовать только в энергозависимом кеше, пока не будут принудительно записаны на диск общесистемной sync ИЛИ явным образом для приложенияfsync своих собственных данных (как указал Джеффри). Если приложение / клиент этого не делает, мы более склонны к потере данных .
Один из способов решить эту проблему - подключить необходимую файловую систему с опцией sync (см.это ветка обсуждения «ext4 и потеря данных» ), и для этого нам нужно назначить ее в двух местах:
- Монтирование в модуль
- Пул хранения OpenEBS ИЛИ хранилище бэкэнда
(В случае 1 мы могли бы иметь цель конвертировать все записи в синхронизацию, как объяснено Джеффри)
В то время как документация mount(8)в частности, говорится, что использование -o sync поддерживается только до ext3 (среди файловых систем ext семейства), ручное монтирование файловой системы с этой опцией принимается.В попытке проверить, разрешено ли это протоколом монтирования, но игнорируется ли ext4, я провел небольшой тест производительности произвольной записи на основе fio для выборки данных размером 256M с диском, смонтированным с опцией синхронизации, и тем же содин без него.Чтобы убедиться, что сами записи не были записью SYNC, был выбран libaio ioengine с direct=1 и iodepth=4 (асинхронный многопоточный небуферизованный ввод-вывод).Результаты показали разницу примерно в 300+ операций ввода-вывода в секунду (разумеется, при улучшенном креплении, отличном от sync).Этот результат говорит о том, что флаг монтирования sync, похоже, играет определенную роль, но я все еще ищу дополнительные доказательства этого.