Я смотрел доклад: «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?