Нужна файловая система для Flash, устойчивая к внезапным отключениям

Что тебе конкретно надо я не знаю, но у меня ext4+lvm+luks, были времена, когда свет вырубался по несколько раз в день, т.е. это, буквально, десятки отключений в месяц. И ни разу с ней не было проблем. Такие дела.

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

Btrfs.

Насколько внезапные отключения совместимы с шифрованными разделами LUKS?

Не влияет.

Что физически более устойчиво к отключениям: USB-NVMe или USB-Flash?

Гранитная плита.

Что физически более устойчиво к отключениям: USB-NVMe или USB-Flash?

Одинаково, и там и там флеш память. Одна разница, что в NVMe больше плотность данных из-за более тонкого и нежного техпроцесса.

Внешний носитель может быть извлечен из компьютера в произвольный момент времени

Организационные проблемы решаются организационными методами.

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

Что тебе конкретно надо я не знаю, но у меня ext4+lvm+luks, были времена, когда свет вырубался по несколько раз в день, т.е. это, буквально, десятки отключений в месяц. И ни разу с ней не было проблем.

Какая конкретика нужна?

В первую очередь при отключениях нельзя допускать потери давно записанных данных, чтобы никогда не возникала ситуация: попытались добавить в каталог новый файл, и при внезапном отключении потеряли целый каталог.

Во вторую очередь, если отключение произошло во время записи новой версии файла, старая версия должна оставаться неповрежденной.

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

Почти любая может и почти любая не может. Но в первую очередь смонтирована должна быть без write cache.

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

Это требования не к ФС, костыляйте свой вариант решения с учетом ваших реалий. Первое что приходит в голову в условиях если кудахтеры ваши это создание временной директории на самом кудахтере, на которую вешаем inotify(для шинды искать что-то подобное у неё под капотом возможности точно есть) по которому:
1. ждем когда запишется
2. переносим это файло на внешний носитель с именем «original-filename.new-version»
3. sync
4. переименовываем original-filename.new-version в original-filename
5. sync
Косяки в этой схеме тоже возможны, но вероятность на них попасть все-таки ниже чем получить битый файл из-за преждевременно выдернутой флэшки.

Одинаково, и там и там флеш память.

Возможно, производители учитывают специфику применения: NVMe изначально предназначены для стационарного использования в отличие от USB-Flash.

NVMe изначально предназначены для стационарного использования в отличие от USB-Flash.

Да, поэтому у них на много лучше производительность случайного доступа.

В первую очередь при отключениях нельзя допускать потери давно записанных данных, чтобы никогда не возникала ситуация: попытались добавить в каталог новый файл, и при внезапном отключении потеряли целый каталог.

Никогда не говори Никогда. Но вот того, что при записи одного файла условно «рубанули питание» и рассыпалась фс, тоже не припоминаю. У меня был достаточно продолжительный период ( >10 <20 лет) работы когда «руки» иногда привозили данные на флэшке, хоть и крайне редко, но случалось, что долбодятлы умудлялись её выдернуть до подтверждения о завершении копирования, рассыпавшейся фс в виде *fat* я не припоминаю.

NVMe изначально предназначены для стационарного использования

Из-за скорости чтения/записи.

Почти любая может и почти любая не может. Но в первую очередь смонтирована должна быть без write cache.

Разумеется, без write cache. Достаточно ли того, чтобы ФС была журналируемой, или следует обратить внимание на другие особенности ФС?

Это требования не к ФС, костыляйте свой вариант решения с учетом ваших реалий.

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

Косяки в этой схеме тоже возможны, но вероятность на них попасть все-таки ниже чем получить битый файл из-за преждевременно выдернутой флэшки.

Какие возможны косяки в этой схеме?

Из-за скорости чтения/записи.

Это понятно. Вопрос в том, может ли это влиять на надежность? Если USB-Flash изначально является съемным носителем, то, возможно, производители могли изначально позаботиться о том, чтобы флешка не повреждалась при внезапных отключениях. Для NVMe это имеет гораздо меньший смысл.

Никогда не говори Никогда.

Почему нет? Не существует ни одной ФС, способной гарантировать работу в таком сценарии?

Достаточно ли того, чтобы ФС была журналируемой, или следует обратить внимание на другие особенности ФС?

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

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

Хорошо. А журналирование может гарантировать, что при добавлении файла в существующий каталог в нем сохранятся другие файлы? Или каталог тоже может превратиться в кучу мусора?

как-будто есть выбор, при таких-то требованиях, смотри btrfs

напиши драйвер работающий в адресном пространстве пользователя

А журналирование может гарантировать, что при добавлении файла в существующий каталог в нем сохранятся другие файлы?

При нормальном железе можно ожидать, что будет нормально. Это же касается Btrfs — контроллеры дисков не должны врать о завершении записи, тогда можно рассчитывать и на целые файлы.

Разумеется, без write cache. Достаточно ли того, чтобы ФС была журналируемой, или следует обратить внимание на другие особенности ФС?

Без разницы.

Я где-то читал, что некоторые ФС могут без костылей создавать что-то вроде контрольных точек.

Это уже другая тема, требующая спец навыков.

Какие возможны косяки в этой схеме?

Если выдернуть на этапе переименования до этапа sync.

Вопрос в том, может ли это влиять на надежность? Если USB-Flash изначально является съемным носителем, то, возможно, производители могли изначально позаботиться о том, чтобы флешка не повреждалась при внезапных отключениях.

Могли позаботиться, могли не позаботиться... какая вам разница? Вы об этом узнаете по факту. Мертвых флэшек я видел немало и срок службы роли не играет.

аналогично (lvm не очень люблю, древнючий mdam моё всё - не удобен, но ускорение приличное даёт) сочетание файл-luks-ext4-home не разу не подводило, не смотря на отключения, ext2 да периодически сыпалось, Btrfs: sqllite а именно браузер часто раком систему ставил, пока для Btrfs в sqllite спец флаг не придумали я sqllite отключай свои примочки хеширования, а то хана.

Сто процентные гарантии только в сберегательной кассе. Но и это уже не работает.

Поэтому у NVME есть SMART и там есть параметр 'unsave shutdowns', с которым никто не знает, что делать :)

И это больше вопрос к прошивке, насколько она правильно написана, они ведь сейчас пишут данные в SLC кеш, потом перекладывают, ещё сборкой мусора занимаются, выравниванием износа. То есть SSD наружу сообщает, что запись ОК, а сам туда сюда что-то пишет и может затронуть любые блоки. Никакая ФС не вытянет, если был блок данных и нету, разве что какое-то полное дублирование (зеркало) на одном носителе...

А ещё у ноутов любит слетать флешка с BIOS, когда работают до полного разряда аккумулятора.

Ну ещё есть чёрные ящики самолётов, там, если повезёт, понадёжнее запись, чем на бытовые SSD :)

Я где-то читал, что некоторые ФС могут без костылей создавать что-то вроде контрольных точек.

Это уже другая тема, требующая спец навыков.

Каких спецнавыков?

Я вспомнил: https://www.opennet.ru/openforum/vsluhforumID3/55372.html

Для хранения всех данных в NILFS2 используются подобные логам структуры, в которых только добавляются новые записи и никогда не переписываются активные. Таким образом оборванная крахом операция записи, никак не отразится на целостности хранимых данных. В NILFS используются B-tree деревья и 64-битные структуры данных, поддерживается возможность фиксации снапшотов (контрольных точек в логе) для просмотра состояния данных на определенный момент времени. Более того с данными в снапшотах можно продолжать работать как с альтернативной веткой ФС, существующей параллельно.

Есть правило никогда не переписывать активные записи. Есть снэпшоты. Кажется, этого достаточно. В чем может быть подвох?

Положи на btrfs и накрой lvmом, как же еще.

Есть правило никогда не переписывать активные записи. Есть снэпшоты. Кажется, этого достаточно. В чем может быть подвох?

Падение производительности.

Положи на btrfs и накрой lvmом,

и сверху обложи матом.

Я бы предложил программное решение:

1. Через inotify отслеживать изменения файлов.

2. При изменениях создавать новый файл вида .filename.xxx, копировать туда данные, после чего через rename переименовывать его в оригинальный файл.

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

4. Использовать ext4.

Альтернативно: использовать базу sqlite в которой хранить файлы. sqlite умеет всё коммитить как положено, чтобы ничего не потерять.

Попробовать Bcachefs: Linux 6.11 (комментарий).
Но Линус может её выпилить в будущих версиях, если его доведут. 🤔

Тут, вроде, напрашивается ядро с атомарным режимом записи. Вот только дождаться, когда в fs это отразится.

обязательно без потери ранее записанных данных.

это задача многослойная.

как выше отметил mky, перед флешкой стоит кэш. То есть, первый вопрос к наличию ионистора в контроллере съёмного носителя, корректности прошивки контроллера (умеет ли она вовремя определить пропажу питания и оперативно сбросить кеши).

Далее идут кэши ОС, в которых тоже что-то имеет свойство застревать. Ну, это параметр настраиваемый, можно покрутить.

И только потом идет вопрос о «надёжности фс».

Предлагаю рассматривать задачу именно в таком порядке.

Падение производительности.

Если это единственный минус NILFS2, то в описанном мной сценарии она более чем уместна.

Существуют ли какие-либо еще известные проблемы с NILFS2?

inotify… .filename.xxx… rename… fsync… ext4…

Примерно так я это и представлял за исключением ext4. В этой схеме я не уверен только в одном. Может ли быть потеряно содержимое каталога, если питание пропадет во фазе rename+fsync?

Существуют ли какие-либо еще известные проблемы с NILFS2?

Да вроде нет.

Может ли быть потеряно содержимое каталога, если питание пропадет во фазе rename+fsync?

Потеряно может быть то, что недописалось.

Существуют ли какие-либо еще известные проблемы с NILFS2?

Никаких!

Не забудь потом создать тему с подробным рассказом о том, как эта хрень рассыпалась.

как выше отметил mky, перед флешкой стоит кэш. То есть, первый вопрос к наличию ионистора в контроллере съёмного носителя, корректности прошивки контроллера (умеет ли она вовремя определить пропажу питания и оперативно сбросить кеши).

И только потом идет вопрос о «надёжности фс».

Я слабо разбираюсь в предмете, но пытаюсь рассуждать логически. Читаю в одном из опиcаний NILFS2:

На что похожа NILFS2? С точки зрения использования: на систему контроля версий SVN. Каждый чекпоинт ФС — это коммит, который делается автоматически без ведома пользователя при любом изменении: будь то удаление, изменение содержимого файла или прав доступа. Каждый коммит имеет номер, который линейно увеличивается.

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

Если некоторые из блоков не успели записаться в постоянную память, весь коммит и следующие основанные на нем можно считать недействительными. Поэтому возможные сбои не должны оказывать влияния на ранее записанные данные.

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

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

Потеряно может быть то, что недописалось.

Это меня и беспокоит. Чем отличается каталог от файла? Только тем, что в нем хранится информация о других файлах. А что такое переименование файла? Это модификация одного или двух каталогов, т.е. перезапись существующей информации.

Я не знаю, как это работает в ext4. Если происходит модификация ранее записанного блока данных, то возможна ситуация, когда сбой по питанию сделает этот блок читаемым некорректно. Тогда часть файлов, находящихся в каталоге станет недоступной.

Зато NILFS2 активные записи не модифицирует.

Прям содержимое - не должно в любом случае. Если ты сделаешь fsync на каталог - не должно потеряться уже никак. Пока не сделал - может предыдущая версия восстановиться из журнала.

Не забудь потом создать тему с подробным рассказом о том, как эта хрень рассыпалась.

А почему NILFS2 должна рассыпаться? И какие ФС не рассыпаются в сценариях, подобных моему?

. А что такое переименование файла? Это модификация одного или двух каталогов, т.е. перезапись существующей информации.

Каталог не модифицируется при переименовании файла лежащего в нем. Но если вы про вариант когда создается каталог и в него заливается один или несколько маленьких файлов, то да, в принципе возможно что и сам каталог тоже пропадет.

Я не знаю, как это работает в ext4. Если происходит модификация ранее записанного блока данных, то возможна ситуация, когда сбой по питанию сделает этот блок читаемым некорректно. Тогда часть файлов, находящихся в каталоге станет недоступной.

Блок чего? Какого-то из файлов лежащего в этом каталоге? Или блок самого каталога?

Если ты сделаешь fsync на каталог - не должно потеряться уже никак. Пока не сделал - может предыдущая версия восстановиться из журнала.

Выше aol упоминал о возможном влиянии внутренних кешей носителей. Мне кажется, именно они и могут внести хаос в журналирование. Чтобы оно работало правильно, требуется соблюдать строгую последовательность записи на физическом уровне. Но алгоритмы кеширования могут менять порядок записи на свое усмотрение.

Насколько ext4 чувствительна к таким перестановкам?

А почему NILFS2 должна рассыпаться?

Потому, что ей никто не пользуется, не? Но ты всё равно попробуй, интересно же. Своё время я на это тратить точно не хочу.

И какие ФС не рассыпаются в сценариях, подобных моему?

Любые CoW не должны. Но очевидно, что у тебя будет кривое железо, так что мой лучший совет — любые, смонтированные в R/O.

Блок чего? Какого-то из файлов лежащего в этом каталоге? Или блок самого каталога?

В том контексте я имел в виду блок данных каталога.

Любые CoW не должны. Но очевидно, что у тебя будет кривое железо, так что мой лучший совет — любые, смонтированные в R/O.

Тут я вообще не понял. NILFS2 как раз CoW, а по условиям задачи R/O совершенно не подходит. К чему такие советы?

NILFS2 как раз CoW

Это волшебным образом делает её пригодной для использования?

а по условиям задачи

Не имеющей отношения к реальному миру, к слову.

В протоколе есть команды синхронизации, при которых устройство должно записать предыдущие записи. ОС их использует при использовании fsync и прочем. Если устройство их не соблюдает, то на нём принципиально невозможно построить ничего надёжного по очевидным причинам и тут никакая ФС не поможет. Нельзя надёжно записать на устройство данные, если устройство их отказывается записывать. Но вряд ли такие устройства легко встретить. На них бы при каждом штатном выключении компьютера терялись бы данные.

Это волшебным образом делает её пригодной для использования?

Я не встречал доказательств непригодности NILFS2. Единственный убедительный довод — о производительности, и мне еще предстоит проверить скорость монтирования после сотен тысяч чекпоинтов.

Если говорить об устойчивости к сбоям по питанию, то практически все источники сообщают об этом как о главном достоинстве NILFS2.

В том контексте я имел в виду блок данных каталога.

У каталога меняется только «access time» так что в условиях, что после его создания в него ещё копируются файлы, он пропасть не должен. Точнее так, вероятность того что и он пропадет, ниже чем вероятность пропажи последнего скопированного файла.