Повреждение файлов при отключении питания и исключениях в процессах

Но ведь даже если мы не работаем с файлом, а в этот момент отключается питание, файл может быть поврежден из-за того, что ОС в фоновом режиме занимается дефрагментацией/индексацией. Это так?

Во-первых, сомневаюсь, что драйвер самостоятельно будет дефрагментировать что-либо (хотя и не буду утверждать обратное), а отсутствие насущности проблемы фрагментации объясняется в первую очередь грамотными алгоритмами выбора блоков для хранения файлов.

А критические, неустранимые ошибки ФС в таких случаях — это практически невероятный сценарий (скажем, внезапный отказ HDD — куда более вероятен). Но повреждения данных (файлов) с которыми велась активная работа в момент отказа — штатная ситуация.

2) Есть ли гарантия, что после возврата управления в программу после функций fclose() или fwrite() данные гарантированно корректно занесены на носитель?

Нет.

• fwrite () гарантирует только занесение данных в пользовательский буфер, но не гарантирует, что эти данные будут переданы ОС. Чтобы принудительно сбросить пользовательский буфер есть функция fflush (). При скоропостижной кончине процесса данные могут быть потеряны.
• fclose () и fflush () сбрасывают пользовательский буфер, но не гарантируют, что ОС передаст данные на носитель. Если процесс умрёт после их возврата, то изменения не потеряются, но они могут быть потеряны в случае внезапного отключения питания.

3) И как контролируется процесс переноса данных из внутреннего промежуточного буфера-кэша жесткого диска на сам носитель?

• Для того чтобы гарантировать запись данных на диск средств Си недостаточно, необходимо пользоваться API ОС. В POSIX-системах (и в linux в частности) есть вызов fsync (). Он гарантирует, что вернёт управление (само собой без ошибки) только после того как данные физически попадут на диск и переживут внезапный отказ системы. В Win API аналогом FlushFileBuffers (), согласно документации он сбрасывает системные буферы, но, гарантирует ли сброс буферов самого HDD или нет, я не знаю.

Как ОС отслеживает перед своим завершением факт того, что данные из буфера накопителя записаны окончательно?

Просто посылает определённую команду HDD. Например, в ATA она так и называется, FLUSH CACHE, опкод E7h. (здесь должен быть ещё десяток оговорок, которые должны быть интересны только разработчикам драйверов)

1. Гарантированную запись на диск можно достичь использованием флага FILE_FLAG_NO_BUFFERING при вызове функции CreateFile(). Способ имеет два минуса
   1. Замедление операций чтения/записи. Чтобы этого избежать, нужно работать с файлом большими буферами, кратными разделу кластера диска. Альтернативой использования этого флага является функция FlushFileBuffers()
   2. Этот флаг гарантирует, что ОС не будет использовать дополнительных буферов, но буферизация есть еще на самом жестком диске. Чтобы отключить буферизацию диска нужно использовать флаг FILE_FLAG_WRITE_THROUGH, но не все устройства этот флаг поддерживают

2. Еще один способ решения проблемы, это писать не в оригинальный файл, а в его копию. А после завершения записи вызывать функцию ReplaceFile() и заменять исходный файл.

   В одной системе у меня используется два идентичных файла данных и к каждому файлу в отдельном файле лежит контрольная сумма. Запись файлов идет в такой последовательности:

   1. Запись основного файла
   2. Запись контрольной суммы этого файла
   3. Запись копии
   4. Запись контрольной суммы копии

   По старту системы я считываю основной файл и проверяю его контрольную сумму. Если совпало — работаем. Если нет — эту пару удаляем и проверяем копию.

3. Ну и классическое решение задачи — зеркальный RAID массив

А вообще все упирается в ценность спасаемых данных. В одной системе мы легко можем потерять базу, восстановить ее из чистого бэкапа и работать. А в другой не спасли ни упсы ни рейды. Экскаватор во дворе зацепил силовой кабель и серверная погибла. Правда в саппорте (вроде тогда еще Dell) сказали ничего не трогать, через неделю приехали специалисты и данные подняли.