LINUX.ORG.RU
ФорумAdmin

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

 ,


0

2

Есть два противоречивых требования:

  • В фоновом режиме по возможности быстро синхронизировать файлы с рабочего SSD компьютера на внешний USB-NVMe или USB-Flash. При любом изменении в одном из рабочих файлов должен быть незамедлительно обновлен соответствующий ему на внешнем носителе.
  • Внешний носитель может быть извлечен из компьютера в произвольный момент времени в ущерб последнему обновлению, но обязательно без потери ранее записанных данных.

Дополнительно:

  • Данные на внешнем носителе должны находиться в шифрованном разделе.
  • Высокая производительность не требуется.

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

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

Вопросы:

  • Существует ли файловая система, способная легко выдерживать внезапные отключения и теряющая данные в худшем случае только последнего синхронизированного файла, а в случае прерванной синхронизации сохраняющая предыдущее состояние файла? Желательно, чтобы файловая система не требовала лечения, а если бы и требовала, то процедура лечения также должна быть устойчивой к внезапным отключениям, т.е. не приводить к потере давно записанных данных.
  • Насколько внезапные отключения совместимы с шифрованными разделами LUKS?
  • Что физически более устойчиво к отключениям: USB-NVMe или USB-Flash? Не приводит ли внезапное отключение USB-NVMe и USB-Flash к потере ранее записанных данных или вообще к повреждению носителя?

Ответ на: комментарий от vbr

если устройство их отказывается записывать

Современное устройство сначала записывает, а потом перезаписывает (перекладывает из кеша, собирает мусор, выравнивает износ). И везде полно рассуждений, что на случай внезапного отключения питания, энтерпрайз SSD содержат конденсаторы (видимо ионисторы), а бытовые отделываются сложными алгоритмами. Но только рассуждения, а тестов нет, так как нужен стенд, отрубающий питание в моменты фоновой активности...

mky ★★★★★
()
Ответ на: комментарий от mky

Но только рассуждения, а тестов нет, так как нужен стенд, отрубающий питание в моменты фоновой активности...

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

anc ★★★★★
()
Ответ на: комментарий от anc

Не совсем пронял про какую дешмань. Многие проводят подобие ресурсного тестирования, им 1-2 т.р. (цена дешёвого SSD) не жалко. А если он ещё и помрёт совсем, так по гарантии можно поменять :)

Но просто так рубить питание через какое-нибудь USB реле, ИМХО, мало толка, нужно с хорошой точностью как-то определять активность NAND памяти и рубить в этот момент. Если подобные стенды и есть, то не дешмань.

Но, зато если тесты покажут УЖОС-УЖОС, то можно поднять продажи ИБП и прочих вундер-вафель. Я как-то натыкался на переходник PCIe-M.2 NVME, на котором типа преобразователь 12В->3.3В и ионисторы — типа микро-ИБП, чтобы SSD успел данные разложить. Правда непонятно, отслеживать ли SSD падение PCIe линка...

mky ★★★★★
()
Последнее исправление: mky (всего исправлений: 1)

Короче хватит паники и ставь ядро 6.11 чтобы была запись либо сделана, либо не сделана. А внезапные отключения страшны разве что когда у тебя всего одна флешка без жесткого диска и сидишь ты в лайв режиме и можешь потерять доступ к компу вовсе таким образом. Какой-то сплошной капец при копеечной цене флешки способной загрузить комп. Хоть со смартфона грузи систему в таком случае по сети. Вайфай такое позволяет.

anonymous
()
Ответ на: комментарий от anonymous

Он не собирается сидеть, он собирается покидать рабочее место с одной флешкой, без компа. И ему не загрузка системы важна, а свои данные, которые он на флешку пишет. Типа пожар и времени мержить в гит нету, бегом убежал, флешка была к руке пристёгнута, поэтом вместе с ней убежал :)

А в 6.11 все ФС стали неубиваемыми, или как?

mky ★★★★★
()
Последнее исправление: mky (всего исправлений: 1)
Ответ на: комментарий от mky

Не совсем пронял про какую дешмань.

Я вот про это:

И везде полно рассуждений, что на случай внезапного отключения питания, энтерпрайз SSD содержат конденсаторы (видимо ионисторы), а бытовые отделываются сложными алгоритмами. Но только рассуждения, а тестов нет, так как нужен стенд, отрубающий питание в моменты фоновой активности...

Бытовые ssd искать надо. Теоретически могли кому-то бытовую хрень менять на кошерный, вот в этом случае оно могло где-то на складе осесть.

Многие проводят подобие ресурсного тестирования, им 1-2 т.р. (цена дешёвого SSD) не жалко.

Им не жалко, а мне жалко, я их не печатаю. 1 т.р. это целых 8 пачек сигарет и ещё на булочку останется.

anc ★★★★★
()
Ответ на: комментарий от mky

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

Но я все же верю в то, что багов в этих алгоритмах мало и наткнуться на них — это надо постараться.

vbr ★★★★
()
Последнее исправление: vbr (всего исправлений: 2)
Ответ на: комментарий от anc

Да тут вначала вобще можно не пытаться убить накопитель, а просто понять, останавливают ли SSD свою активность при получении команды idle/stop при штатном подключении и при подключении через USB-переходник. Если как-нибудь по ЭМИ полю определять, что NAND чип выполняет команды записи/стирания...

mky ★★★★★
()
Ответ на: комментарий от newbie24

Если это единственный минус NILFS2

Там есть еще минус, что удоление файла не освобождает, а занимает место. Когда-то оно вроде освобождается, но может быть и через неделю)

goingUp ★★★★★
()
Последнее исправление: goingUp (всего исправлений: 1)
Ответ на: комментарий от goingUp

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

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

mky ★★★★★
()
Ответ на: комментарий от mky

Там запись на блочные устройства переделали чтобы исключить вариант недозаписи. То что флешка может быть m.2 накопителем подключенным по USB ничего не меняет. Просто контролер станет быстрее. Сама работа может быть полностью из оперативной памяти и там никак не нагружается накопитель после загрузки. Ну куда лучше то уже? Разве что если про размер думать, но и SD карты вроде как новые сверхбыстрые появляться начали. несколько сотен мегабайт в секунду хватит за глаза запись сделать.

anonymous
()

Linux 6.11

Добавлена поддержка операций атомарной записи на блочном уровне, при которых на накопитель записывается либо весь указанный набор блоков, либо ни один из блоков. Это может предотвратить ситуации, когда после сбоя оборудования или по иной причине записывается лишь часть блоков, а в другой части остаётся старая информация. Включение атомарного режима записи осуществляется системным вызовом pwritev() в который добавлен флаг RWF_ATOMIC.

anonymous_sama ★★★★★
()
Ответ на: комментарий от vbr

Но я все же верю в то, что багов в этих алгоритмах мало и наткнуться на них — это надо постараться.

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

Комментаторы выше правы: нужен испытательный стенд.

newbie24
() автор топика
Ответ на: комментарий от mky

Если как-нибудь по ЭМИ полю определять, что NAND чип выполняет команды записи/стирания…

Один из простых вариантов: отслеживать изменения тока питания флешки. Но тоже надо проверять, насколько они отличимы от шума.

Со стендом вопросов пока больше чем ответов. Скорее всего, это вопрос отдаленного будущего.

Для начала я планирую проверять свою систему сразу в боевых условиях: компактный USB-hub c двумя компактными флешками разных производителей; на флешках разные файловые системы; запись на флешки поочередная, очередность выбираем случайно, все обращения логируем; при любых обстоятельствах воспроизводим экстремальные условия, т.е. всегда отключаем флешки, выдергивая хаб из разъема; при подключении хаба всегда выполняем тестирование ФС и данных, результаты сохраняем в логи.

newbie24
() автор топика

Я бы попробовал:

  1. флеху с ext4 с опцией монтирования sync
  2. syncthing с настройкой на выгрузку файлов в точку монтирования флешки с включённым версионированием

Но есть у меня подозрение что флешки будут вырабатывать ресурс за неделю-полторы.

Пока не попробуешь не узнаешь.

anonymous
()