Лучший способ защитить встроенный файловый сервер ext4 от неожиданной потери питания?
Во-первых, немного предыстории: моя компания создает потоковое аудиоустройство, которое представляет собой безголовый, монтируемый в стойку блок Linux с твердотельным накопителем e-SATA. Диск отформатирован с ext4. Пользователи могут подключаться к системе с помощью Samba/CIFS для загрузки новых аудиофайлов или доступа к существующим. Существует также специальное программное обеспечение для потоковой передачи звука по сети.
Это все хорошо. Единственная проблема заключается в том, что пользователи - это люди со звуком, а не люди, работающие на компьютере, которые рассматривают систему как "черный ящик", а не как компьютер. Это означает, что в конце дня они не собираются входить в систему через ssh и вводить "/sbin/shutdown -h"; они просто отключат питание стойки и уйдут, и ожидают, что все будет работать должным образом на следующий день.
Поскольку в ext4 есть журналирование, контрольная сумма в журнале и т. Д., Это в основном работает. Единственный раз, когда это не работает, это когда кто-то загружает новый файл через Samba, а затем отключает питание системы до того, как загруженные данные будут полностью записаны на диск. В этом случае они приходят на следующий день и обнаруживают, что их новый файл был усечен или отсутствует полностью, и они недовольны.
У меня вопрос, как лучше всего избежать этой проблемы? Есть ли способ заставить smbd вызывать "sync" в конце каждой загрузки? (Производительность при загрузке не так важна, так как они происходят только изредка). Или есть ли способ сказать ext4, чтобы автоматически сбрасывать в течение нескольких секунд при любом изменении файла? (Опять же, производительность может быть принесена в жертву ради безопасности здесь). Должен ли я установить определенный режим порядка записи, активировать барьеры и т. Д.?
3 ответа
Монтирование файловой системы с sync указанное в fstab, вероятно, поможет. Я подозреваю, что у кого-то будет рекомендация, лучше подходящая для вашего конкретного применения.
Я начал первоначальные исследования по файловым системам, используемым с флеш-хранилищем, так как я хочу создать персональный компьютер для домашнего кинотеатра в качестве устройства. Вы можете найти другое решение для хранения данных, более подходящее для вашего устройства. К сожалению, я еще не нашел то, что предпочитаю, поэтому у меня нет там подробных рекомендаций.
Редактировать 1
Согласно man-странице smb.conf(5), он поддерживает немедленную синхронизацию в SAMBA:
strict sync (S)
Many Windows applications (including the Windows 98
explorer shell) seem to confuse flushing buffer
contents to disk with doing a sync to disk. Under
UNIX, a sync call forces the process to be sus-
pended until the kernel has ensured that all out-
standing data in kernel disk buffers has been
safely stored onto stable storage. This is very
slow and should only be done rarely. Setting this
parameter to no (the default) means that smbd(8)
ignores the Windows applications requests for a
sync call. There is only a possibility of losing
data if the operating system itself that Samba is
running on crashes, so there is little danger in
this default setting. In addition, this fixes many
performance problems that people have reported with
the new Windows98 explorer shell file copies.
Default: strict sync = no
sync always (S)
This is a boolean parameter that controls whether
writes will always be written to stable storage
before the write call returns. If this is no then
the server will be guided by the client's request
in each write call (clients can set a bit indicat-
ing that a particular write should be synchronous).
If this is yes then every write will be followed by
a fsync() call to ensure the data is written to
disk. Note that the strict sync parameter must be
set to yes in order for this parameter to have any
affect.
Default: sync always = no
Да, я работал с той же проблемой. Если вы отключите какой-либо вид кэширования записи в системе, любые данные будут записаны на диск как можно скорее.
Вы потеряете производительность, но вы получите лучшую целостность данных.
Разница между данными на диске и тем, что операционная система считает на диске (но на самом деле она кешируется в памяти), будет значительно ниже.
Если вы не можете использовать ИБП для решения или какое-либо аппаратное решение, которое изящно отключает машину в случае потери питания от сети переменного тока, вам придется использовать такие хаки.
Может быть идея использовать гораздо более простую файловую систему для хранения носителей и загрузки операционной системы с виртуального диска. Таким образом, исключается возможность испортить загрузочный / корневой раздел машины.
Подводя итог,
Смонтируйте файловую систему с синхронизацией, вы потеряете производительность, однако все записи не будут кэшироваться.
Отключите аппаратные дисковые кеши, снова вы потеряете производительность.
Эта статья должна быть интересна для вас
Поскольку вы упоминаете, что ваша компания их создает, я бы рекомендовал взглянуть на аппаратный аспект. Я видел серверы с резервными батареями на контроллерах дисков, чтобы позволить кэшированным данным пережить потерю энергии. Что, если ваши инженеры встроили небольшую батарею, чтобы система работала достаточно долго, чтобы выключить систему? Это не должен быть большой отдельный ИБП, он может быть внутренним и настроен на отключение системы, как только пропадет питание кондиционера. Это может добавить несколько долларов к стоимости, но это также может быть маркетинговым пунктом.