Во-первых, небольшая предыстория: моя компания производит устройство для потоковой передачи звука, представляющее собой монтируемый в стойку Linux-бокс с твердотельным накопителем e-SATA. Диск отформатирован с помощью ext4. Пользователи могут подключаться к системе с помощью Samba / CIFS для загрузки новых аудиофайлов или доступа к существующим. Также существует специальное программное обеспечение для потоковой передачи звука по сети.
Все в порядке. Единственная проблема заключается в том, что пользователи - люди со звуком, а не с компьютерами, и видят систему как «черный ящик», а не как компьютер. Это означает, что в конце дня они не собираются подключаться по ssh к ящику и вводить "/ sbin / shutdown -h"; они просто отключат питание стойки и уйдут, ожидая, что на следующий день все будет нормально работать.
Поскольку в ext4 есть ведение журнала, контрольная сумма журнала и т. Д., Это в основном работает. Единственный раз, когда это не работает, это когда кто-то загружает новый файл через Samba, а затем отключает питание системы до того, как загруженные данные будут полностью сброшены на диск. В этом случае они приходят на следующий день и обнаруживают, что их новый файл был обрезан или полностью отсутствует, и недовольны.
У меня вопрос, как лучше всего избежать этой проблемы? Есть ли способ заставить smbd вызывать "синхронизацию" в конце каждой загрузки? (Производительность при загрузках не так важна, поскольку они случаются только изредка). Или есть способ указать ext4 автоматически очищаться в течение нескольких секунд после любого изменения файла? (Опять же, производительностью здесь можно пожертвовать ради безопасности) Следует ли мне устанавливать определенный режим упорядочивания записи, активировать барьеры и т. Д.?
Да, я работал с той же проблемой. Если вы отключите какой-либо вид кэширования записи в системе, любые данные будут записаны на диск при первой возможности.
Вы потеряете производительность, но улучшите целостность данных.
Разница между данными на диске и тем, что, по мнению операционной системы, находится на диске (но на самом деле они кэшируются в памяти), будет значительно меньше.
Если вы не можете использовать ИБП в качестве решения или какое-либо аппаратное решение, которое плавно отключает машину при отключении питания от переменного тока, вам придется использовать подобные хаки.
Это может быть идея использовать гораздо более простую файловую систему для хранения носителей и загрузки операционной системы с RAM-диска. Таким образом, избегая шанса повредить загрузочный / корневой раздел машины.
Итак, чтобы резюмировать,
Смонтируйте файловую систему с синхронизацией, вы потеряете производительность, однако все записи не будут кэшироваться.
Отключите аппаратные кеши записи на диск, снова потеряете производительность.
Эта статья должна вас заинтересовать
Монтирование файловой системы с помощью sync указанный в fstab, вероятно, поможет. Я подозреваю, что у кого-то будет рекомендация, лучше подходящая для вашего конкретного приложения.
Я начал первоначальное исследование файловых систем, используемых с флеш-накопителями, так как я хочу создать персональный компьютер для домашнего кинотеатра в качестве устройства. Вы можете найти другое решение для хранения, более подходящее для вашего устройства. К сожалению, мне еще предстоит найти то, что я предпочитаю, поэтому у меня нет подробных рекомендаций.
Редактировать 1
Согласно справочной странице 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
Поскольку вы упомянули, что их производит ваша компания, я бы порекомендовал взглянуть на оборудование. Я видел серверы с резервным аккумулятором на контроллерах дисков, чтобы кэшированные данные сохранялись при потере питания. Что, если бы ваши инженеры встроили небольшую батарею, чтобы система работала достаточно долго, чтобы полностью завершить работу? Это не обязательно должен быть большой отдельный ИБП, он может быть внутренним и настроен на отключение системы при отключении питания переменного тока. Это может добавить несколько долларов к стоимости, но это также может быть маркетинговый пункт.