Здравствуйте, valuea, Вы писали:

V>Здравствуйте, VVB16, Вы писали:
V>Я конечно могу ошибаться, но вот что вижу

...

V>А также writes in async mode, and then wait for i/o to complete.

О, интересно. А это не частный случай, когда все сбрасывается?
Я в таких случаях ориентируюсь на man, а там указано, что записываются в fs, на не на storage device.
А вот в fsync(2) явно написано то, что надо. Собственно я делал msync и следом fsync, для гарантии соотвествия букве манула.

VVB>>На самом деле ситуация такая — если нужны гарантии на выполнение транзакции, надо ждать ее завершения. Если не ждать — нет гарантий.
V>Ну я подразумеваю все-таки немного разные ситуации:
V>1. Гарантия консистентности данных
V>2. Гарантия актуальный ответа вызывающей системе о состоянии данных в результате выполнения транзакции
V>То есть вызывающая система получает ответ об успешном завершении транзакции, хотя изменения в рамках данной тарнзакции могут быть и не сохранены. Данная гарантия теряется в угоду производительности, но гарантия консистентности данных все-же сохраняется.

Консистентность в памяти будет, на диске — нет, пока fsync не вернулся.
Надо ж учитывать, что переупорядочить запись может много кто (контроллер, сам диск) и только правильно реализованный fsync даст гарантию, что на диске лежит то, что мы записали.
Можно делать так: заголовок обновлять периодически, в отдельном потоке, вместе со сбросом данных на диск. А клиентам возвращать состояние в памяти.
Точнее даже так — сбрасываем данные fsync'ом, потом только обновляем заголовок и опять fsync. Тогда заголовок содержит заведомо правильную информацию.
В свое время я с этими тонкостями разбирался глядя на решения в BerkeleyDB, как там тот же журнал сделан, например.