Безопасно ли снова вызывать функцию Win32 FlushFileBuffers(), если она ранее вернула ошибку?
Я смотрел доклад: "PostgreSQL против fsync. Как это возможно, что PostgreSQL неправильно использовал fsync в течение 20 лет, и что мы будем с этим делать". через https://fosdem.org/2019/schedule/event/postgresql_fsync/ а также прочитайте https://lwn.net/Articles/752063/ качестве фона.
Очень короткая и упрощенная сводка - для Linux, если вы вызываете fsync(), и он не работает, не думайте, что вы можете вызвать fsync() снова, чтобы исправить это, так как во второй раз вызов будет успешным, и у вас будут поврежденные данные на диске (страницы с ошибочным буферным кешем помечаются как чистые после первого неудачного вызова). Существует много деталей относительно того, почему это происходит (поддерживает случай, когда USB извлекается - вы не хотите повторять попытки и держаться за грязные страницы буферного кеша, которые никогда не могут быть успешными).
Как ведет себя FlushFileBuffers() в этой ситуации? Меня особенно интересуют файлы, доступ к которым осуществляется через CIFS, где сбои более вероятны.
Кроме того, учитывая, что ОС может в любое время в фоновом режиме пытаться записать грязные страницы буферного кэша в стабильное хранилище, как программы, выполняемые пользователем, могут обнаруживать эти сбои с помощью Win32 API?