Файловая система, которая никогда не ломается (потеря данных допустима)

Есть несколько существующих тем, вращающихся вокруг этой проблемы, но то, что я ищу, немного отличается. У меня есть SD-карта на встроенном Linux, и он страдает от потери питания. Возможно, я смогу изменить аппаратное обеспечение в какой-то момент, правильно закрыть и т. Д. И т. Д. Но сейчас я просто хотел бы найти файловую систему, которая без сбоев выживет. Потеря данных приемлема. Я предпочел бы не потерять больше, чем файл, который я сейчас пишу, но я все равно предпочел бы потерять все это, чем столкнуться с «неспособностью смонтировать», «подождать 10 минут fsck» или «не может создать новый файл из-за этого inode что-то что-то ошибка ». Программа ДОЛЖНА продолжаться!

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

Мой лучший выбор сейчас - использовать JFS на SD-карте, включая fsck и fsck.jfs в мою установку. (Добавление 600kb + еды моего оперативной памяти и флэш-памяти. Что плохо.) И запускайте fsck при каждом запуске (возможно, добавляя много времени загрузки. Что несколько плохо.). Это кажется немного грустным, хотя.

Кто-нибудь знает о лучшем способе или лучшей файловой системе?

ОБНОВЛЕНИЕ: e2fsprogs-libs (зависимость от jfsutils), похоже, адски сложно скомпилировать в моем дистрибутиве. Я посмотрю на ZFS (хотя он не является родным для моего дистрибутива. И, похоже, он делает многое из того, что мне не нужно.)

ОБНОВЛЕНИЕ 2: Еще немного информации о моей системе и моих тестах: Память на SD-карте является дополнительной, дополнительной памятью. Карты SD - 2Gb-8Gb промышленного класса microSD. SD-карта монтируется через мой rc с помощью команды mount -t. Опции "noatime", но не "sync". Мой дистрибутив - пользовательский uClinux со вкусом аналогового устройства, с ядром 3.10 и 1.21 busybox. Мое основное хранилище - это spi flash с jffs2. У меня никогда не было проблем с этим. Я даже не знаю, есть ли доступный fsck.jffs2. Нанд флеш с другой стороны ... но это другая история. Назначение SD-карты - хранить данные измерений. Программа 'monitor' добавляет результаты в файл и имеет стратегическую синхронизацию. Когда размер файла превысит заданный размер, будет создан новый файл. При достижении заданного количества файлов самый старый будет удален. Если текущий файл измерений теряется из-за потери мощности, это не беда. Файлы обычно имеют размер 50-100 КБ, а 1 результат обычно составляет 1 КБ. Это только начальная фаза разработки. Ничто не исправлено. Это первый раз, когда я имею дело с файловыми системами без флэш-памяти во встроенных системах. (Я получил ext4 на моих серверах x86.)

Я начал с vfat. Файловая система по умолчанию. (Я подумал, что у заводов может быть причина для его выбора. И если что-то работает, меня это особо не волнует.) Я никогда не видел проблем с потерей мощности во встроенных устройствах vfat. У меня возникли проблемы с FAT в WinCE. Однако, когда моя программа 'monitor' достигла 100-200 файлов, она больше не создавала. Кажется, что у FAT есть особая проблема с ограничением количества файлов в корне и немного больше в подпапках. Мне нужно иметь возможность создавать 500-1000 файлов в 1 директории. Так что vfat не подойдет.

Затем я переключился на ext2. Я не вставил fsck при запуске, хотя. (Не знал, что я должен был это сделать.) В течение дня моя программа-монитор не смогла создать больше файлов из-за ошибки «что-то из inode». Стихийное бедствие!

Мое текущее решение - ext2 с "e2fsck -y" при запуске. Пока это кажется многообещающим. Но e2fsck и вся концепция «fsck при запуске» мучают меня. Сам e2fsck тратит более 350 КБ моей основной вспышки и оперативной памяти. (Когда он не работает.) Это означает, что это моя самая большая программа. Это больше, чем busybox. Это почти соперничает с моим ядром.

Я рассматривал ext3. В нем есть метаданные, которые не повредят. Я сомневаюсь, насколько это поможет. Я думаю, что с моими небольшими файлами и контролируемой синхронизацией я должен быть покрыт? Имеет упорядоченную последовательность записи. Это означает, что данные также несколько записаны в журнал. Это, однако, может привести к недетерминированным задержкам. Что плохо в моей ситуации. (Это, вероятно, не проблема.) Он также имеет функцию синхронизации по расписанию. Например. совершать каждые 5 сек. Который мешает моей собственной синхронизации, я думаю. Слишком много записей плохо для SD-карт. Даже промышленные. Я не могу найти документацию о том, как отключить это. И ext3 по- прежнему требует запуска fsck при каждом запуске! Но ext3 все еще возможна.

Ext4. Устранит множество проблем с производительностью ext3. Мне не очень нужна производительность. И в моем дистрибутиве нет встроенных mkfs.ext4 и fsck.ext4. Возможно, это не проблема. Это может хотя. Например. У e2progs-libs (зависимость от jfsutils), похоже, много проблем с компиляцией.

JFS, XFS, BRFSS. Все поддерживается моим ядром. В настоящее время не включены в мой ящик для инструментов пользовательского пространства. Все кажется довольно большими, сложными системами. И все они, кажется, требуют эквивалент 'fsck' при запуске?

Я также подумал о создании собственной файловой системы: всегда пишу 2 копии таблицы файлов. При обходе выбирается тот, который имеет правильный CRC и самый новый порядковый номер. Сделайте двухэтапную последовательность записи. Выделить временно, исправить при фиксации. Fsck не требуется. Боюсь, это может быть немного наивно.

ОБНОВЛЕНИЕ 3: Кстати, природа встроенных систем (по крайней мере, этой) заключается в том, что они автономны, без присмотра, вне досягаемости, и им приходится работать годами. Такие программы, как fsck, которые могут потребовать взаимодействия с человеком, меня пугали.

В вашей истории есть некоторая несогласованность или, по крайней мере, двусмысленность:

Я все же предпочел бы потерять все это, чем столкнуться с «неспособностью смонтировать», «подождать 10 минут»

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

Кажется, что e2fsprogs-libs (зависимость от jfsutils) адски трудно компилировать в моем дистрибутиве.

Это означает, что у вас нет fsck вообще , так e2fsprogs-libsкак это зависимость, e2fsprogsкоторая обеспечивает e2fsck. Так что, возможно, вы все еще находитесь в стадии планирования и даже не тестировали систему, например ext4, но вместо этого пришли к выводу, что вам следует начать с JFS? Есть ли какая-то конкретная причина для этого?

Я заметил на Rasberry Pi Exchange (основное хранилище пи также SD-карта), что значительное количество пользователей, похоже, очень разочарованы проблемами такого рода, хотя большинство (включая меня) никогда не сталкивались с все. Сначала я предположил, что это люди, которые не знают о том, что система должна быть полностью отключена, но это не трудно понять, когда объясняют, и есть люди, которые сообщают об этом, даже если система была выключена должным образом .

Вы уже сказали, что это нужно для того, чтобы выдерживать перебои в подаче электроэнергии (что вполне справедливо), но я упоминаю об этом, потому что это подразумевает, что есть какие- то пи, или несколько SD-карт, или некоторая комбинация обоих, которые просто подвержены повреждение файловой системы из-за какого-то события (всплеска?), которое происходит регулярно, либо когда вилка извлечена, либо когда она вставлена ​​обратно. Я также НЕ видел - и у многих было достаточно времени, чтобы попробовать - ЛЮБЫЕ сообщения о том, что кто-то сказал, что они перешли на btrfs или jfs или что-то еще, и теперь проблема решена.

Другая загадочная вещь в этом - даже если люди дергают за шнур, это не должно регулярно приводить к непригодности файловой системы. Конечно, я делал это пару раз с пи, и десятки, если не сотни раз, с обычным Linux-боксом (отключение питания, система перестала отвечать, я измотан и зол и т. Д.) и хотя я видел незначительную потерю данных, я никогда не видел, чтобы файловая система была повреждена до такой степени, что ее невозможно было использовать после быстрого fsck.

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

На пи я пишу , -yчтобы /forcefsckв загрузочном скрипте, так что при следующей загрузке он запускается автоматически и все проблемы решаются, независимо от того, появляется ли это необходимо или нет. На одноядерном сервере с частотой 700 МГц это занимает ~ 10 секунд для файловой системы 12 ГБ, содержащей ~ 4 ГБ данных. Так «10 минут» звучит как невероятно долго, тем более , что вы уже сказали «Это есть небольшая файловая система для записи!».

Вы также можете рассмотреть возможность звонков syncчерез регулярные промежутки времени.

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

Программа ДОЛЖНА продолжаться!

Ну, это общее требование, и системы Linux - лучший выбор, когда речь идет о выборе стабильной системы.

Ваши усилия, кажется, также не идут в правильном направлении. Однако что вы можете сделать, чтобы получить стабильную систему?

На первом уровне вы можете улучшить свою файловую систему:

• Использовать yournal_data_orderedв ext3/ext4файловой системе при создании или изменении с tune2fs.
• С JFSиспользованием --replay_journal_onlyпри проверке.
• Включите авторемонт, установив FSCKFIX=yesв начальных кодах.

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

На следующем уровне вам нужно оставить встроенную систему и прочитать некоторые темы о высокой доступности