Могу ли я использовать O_DIRECT для запросов на запись, чтобы избежать потери данных при сбое питания?

Question

Мы хотим попробовать свои силы, чтобы избежать потери данных при сбое питания.Поэтому я решил использовать флаг O_DIRECT, чтобы открыть файл для записи данных на диск.О_DIRECT означает, что данные полностью обходят кеш ОС?Если запрос возвращается в приложение успешно, означает ли это, что данные должны быть сброшены на диск?Если я открою обычный файл в одной файловой системе, как насчет метаданных FS?Он также немедленно очищается или кэшируется?

Кстати, O_DIRECT можно использовать в Windows?Или есть какой-нибудь соответствующий метод в Windows?

Answer 1

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

Answer 2

Вы можете использовать O_DIRECT, но для многих приложений вызов fdatasync () более удобен.O_DIRECT накладывает множество ограничений, потому что IO полностью обходят кеш ОС.Он обходит как кэш чтения, так и кэш записи.

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

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

Answer 3

CreateFile может сделать это.

HANDLE WINAPI CreateFile(
  __in      LPCTSTR lpFileName,
  __in      DWORD dwDesiredAccess,
  __in      DWORD dwShareMode,
  __in_opt  LPSECURITY_ATTRIBUTES lpSecurityAttributes,
  __in      DWORD dwCreationDisposition,
  __in      DWORD dwFlagsAndAttributes,
  __in_opt  HANDLE hTemplateFile
);

Для dwFlagsAndAttributes вы можете указать FILE_FLAG_WRITE_THROUGH и FILE_FLAG_NO_BUFFERING.

Если указаны оба значения FILE_FLAG_WRITE_THROUGH и FILE_FLAG_NO_BUFFERING, так что системное кэширование не действует, то данные немедленно сбрасываются на диск, не проходя через системный кеш Windows .Операционная система также запрашивает запись локального аппаратного кэша жесткого диска на постоянные носители.

Answer 4

Можно ли использовать O_DIRECT для запросов на запись, чтобы избежать потери данных при сбое питания?

Нет!

В Linux, пока O_DIRECT пытается обойти вашу операционную систему кеширует ее никогда не обходит кеш вашего диска 1011 *. Если ваш диск имеет энергозависимый кэш записи, вы все равно можете потерять данные, которые были только в дисковом кеше, при внезапном отключении питания!

Означает ли O_DIRECT, что данные полностью обходят кэш ОС?

Обычно, но некоторые файловые системы Linux могут использовать буферизованный ввод / вывод с O_DIRECT ( Ext4 Wiki, разъясняющий семантику Direct IO страница предупреждает, что это может произойти при выделении записей ).

Если запрос возвращается в приложение успешно, означает ли это, что данные должны быть сброшены на диск?

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

Если я открою обычный файл в одной файловой системе, как насчет метаданных FS? Это также немедленно очищается или кэшируется?

Отличный вопрос! Метаданные все еще могут перемещаться в кеше и еще не синхронизироваться с диском, даже если запрос завершен успешно.

Все вышеперечисленное означает, что вам НЕОБХОДИМО выполнить соответствующую команду fsync() в правильных местах (и проверить их результаты!), Если вы хотите быть уверены, что операция достигла энергонезависимой памяти. Подробнее см. https://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/ и статью LWN «Обеспечение доступа к диску» .