Какая файловая система предлагает лучшую защиту для защиты данных от повреждения из-за потери питания?

Я бег небольшого uClibcи busyboxвстроенная система , основанную на x86 - устройстве. Я использую initramfs, но я также монтирую пользовательский ext3каталог на компактном флэш-устройстве в режиме IDE, который я использую для хранения постоянных данных регистрации измерений, созданных пользовательским приложением c ++. Я выбрал ext3файловую систему, так как она рекомендуется для обеспечения безопасности от потери питания при использовании дисков CF в режиме IDE в нескольких книгах, которые я прочитал (« Сборка встраиваемых Linux-систем » Карима Ягмура и « Embedded Linux Primer » Кристофера Халлинана). Это особенно важно, и данные являются критическими.

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

1. На ext3самом деле лучший выбор для этой установки?
2. Потеря питания во время операции записи на диск только повреждает часть данных, которые я периодически добавляю в файл, или это может повредить весь файл?
3. Являются ли данные, которые не записываются в момент потери питания, полностью безопасными? В частности, есть ли риск, что мой initramfs.cpioфайл также может быть поврежден?
4. Есть ли какой-либо метод, который я могу использовать в своем коде приложения для защиты данных (например, создание дополнительного раздела и запись моих данных для зеркального отображения изображений, чтобы всегда было 2 копии) - скорость не является реальной проблемой для моего приложения, поэтому дорогостоящие операции копирования приемлемы

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

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

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

Некоторые из этих машин даже работали в не журналируемых файловых системах (обычно ufs и ext2). Некоторые из них были встроенными, а некоторые были мобильными телефонами, такими как Nokia N900 - поэтому хороший источник питания вообще не гарантировался.

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

В ответ на ваши буквальные вопросы:

1. По крайней мере, первая книга, на которую вы ссылались, была написана ранее ext4- когда автор предлагает использовать ext3, они действительно говорят «не используйте нестабильные или не журналируемые файловые системы, подобные ext2»). Попробуйте ext4, он довольно зрелый и имеет несколько приличных опций для не вращающихся дисков, которые могут продлить срок службы вашего флэш-устройства.
2. Скорее всего, он потеряет последний или два блока, а не весь файл. С журналированной файловой системой это будет единственной потерей. Есть сценарии сбоев, в которых я вижу случайные данные, разбросанные по файлу, но они кажутся такими же вероятными, как микрометеорит, прорывающийся прямо через встроенное устройство.
3. Смотрите 2. Ничто не на 100,00% безопасно.

4. Если у вас есть второй канал IDE, вставьте туда вторую CF-карту и периодически собирайте резервную копию файловой системы. Есть несколько способов сделать это: rsync, cp dump, dd, даже при использовании md(4)(программное обеспечение RAID) устройства (добавить второй диск иногда, пусть это синхронизировать, а затем удалить его - если оба устройства находятся под напряжением все время, они бегут такой же риск повреждения файловой системы). Если вы используете LVM, вы можете даже сделать снимки. Для встроенного устройства сбора данных я бы просто использовал специальное решение, которое монтирует вторую файловую систему, копирует журнал данных и немедленно отключает его. Если вы беспокоитесь о том, что устройство имеет хороший загрузочный образ, вставьте вторую копию менеджера загрузки и все необходимые загрузочные образы на второе устройство и настройте компьютер для загрузки с любой CF-карты.

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

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

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

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

Вы сказали, что производительность не является большой проблемой, поэтому используйте ее разумно fsync().

Потеря питания во время операции записи на диск только повреждает часть данных, которые я периодически добавляю в файл, или это может повредить весь файл?

Я лично использую файловые системы extN и на интернет-серверах с низким средним трафиком в течение многих лет, и, как и Алексиос, я не видел много повреждений из-за сбоя питания (хотя, честно говоря, на серверах есть ИБП, и я не могу вспомнить один из них на самом деле идет по этому пути). Гораздо более серьезной проблемой является повреждение из-за аппаратного сбоя, из-за которого различные файловые системы могут (опять-таки) быть в той или иной степени способными справиться с проблемой, но (опять-таки) это принципиально вне их контроля, и они не могут предотвратить ее.

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

Являются ли данные, которые не записываются в момент потери питания, полностью безопасными? В частности, есть ли риск, что мой файл initramfs.cpio также может быть поврежден?

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

Есть ли какой-либо метод, который я могу использовать в своем коде приложения для защиты данных?

Стоит повторить пункт о fsync () . Объекты C ++ / iostream не имеют метода для этого (:: flush и :: sync не являются fsync), но все, что вам нужно, - это файловый дескриптор.

ZFS - определенно файловая система, защищенная от коррупции по замыслу и, возможно, единственная. Однако я не уверен в доступности реализаций ZFS (на основе fuse или native) для платформ на основе uClinux.

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

Недостатком является то, что это очень дорого, с другой стороны, они предлагают отличную поддержку. Из-за расходов, это действительно единственный вариант для больших ставок и / или продуктов с большим объемом. Как критическое встроенное оборудование, например, для добычи нефти и газа, которое должно обеспечивать целостность системы в «неопределенных» условиях эксплуатации (например, частые отключения электроэнергии и т. Д.).

Проверьте DataLight (компания) и / или продукт " Reliance NITRO ". (Reliance - это их устаревшее и безопасное, но не очень эффективное решение, заменяемое Reliance NITRO ). Даже если у вас нет денег, чтобы использовать эту систему, у них есть довольно хорошие статьи, в которых обсуждается, как работает их система, почему она более надежна, чем, например, ext3 и ext4.

Мои извинения, если это читается как реклама, просто хотел указать на варианты.