Позволяет ли такой алгоритм откатить последнюю запись в файле в случае фейла питания?

Я бы хранил чексуммы вместе с оффсетами в отдельном индексном файле, блоки переменной длины и без индексов - это будет тормозить.
А еще я бы не дергал fsync писят раз, зачем?

Первый fsync лишний.

fsync() я дёргаю 50 раз как дебил затем, что ядру/ФС никто не мешает переупорядочить запись: оно может успешно записать header последующей записи и последующую запись, а потом начать записывать предыдущую запись и обломиться. Так я потеряю 2 записи. Хотя это маловероятно наверное в случае больших payload.

Я имею ввиду:

write header1
write data1
write header2
write data2

может реализоваться такой цепочкой событий, если нет fsync():

write header2
write data2
write data1
FAIL

Первый fsync лишний.

Похоже на то.

То есть ты понял, что порядок записи неважен?

То есть ты понял, что порядок записи неважен?

Да, неважен порядок между write(header1) и write(data1), лишь бы оба записались. А потом вот можно сделать fsync() перед новой записью.

если у него append-only лог который надо редко читать то зачем? В противном случае индекс можно держать в памяти.

Первое, о чём я подумал - не изобретать велосипед и заводить для каждой записи отдельный файл, переименовывая его после close(). Очень просто и очень надёжно, авторы ФС умные люди и уже давно всё продумали и на все грабли понаступали.

авторы ФС умные люди и уже давно всё продумали и на все грабли понаступали.

Ты имеешь ввиду авторов btrfs, у которой метаданные сжирали полдиска за раз, или автора reiserfs, который продумал далеко не всё?

Автор reiserfs не продумал как избавиться от жены не оставив следов? Было ещё что-то? Она основана на принципе B-дерева, этого достаточно. А вот XFS в контексте обсуждения упомянуть более уместно, она как раз и устроена на схожем принципе.

А как насчет неконтролируемого ОС кэша HDD?

Кэш HDD будет записан за счёт энергии раскрученых блинов.

Алгоритм складный.

А как насчет неконтролируемого ОС кэша HDD?

Вот насчет этого надо читать. Если HDD не гарантирует сброс кэша в случае сбоя питания и размер кэша больше размера записи, то нельзя гарантировать <= одной битой записи.
Тогда нужно уходить на отдельный накопитель для данных (флеш без кэша), возможно стоит и без ФС на нем тогда обойтись (и забыть плясках и спорах вокруг fsync).

Ты имеешь ввиду авторов btrfs

Этих я вообще ввиду не имею, странно, что они не использовали nodejs или php вместо си, это бы было гармонично.

Открываем файл сначала и последовательно проверяем

А если файл разрастется?

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

Данные в файле, кстати, могут испортиться и в середине: https://en.wikipedia.org/wiki/Data_corruption#Silent . То есть для увеличения надежности нужно держать еще какую-то избыточность.

В этом вопросе хорошо бы вовремя остановиться. Для многих приложений держать хэши данных уже лишнее

В звисимости от выбранной ФС у тебя может случиться всякое, начиная от битого файла, заканчивая разрушением ФС.

Я бы сделал файл фиксированной длины, который пишется по кольцу блоками одинаковой длины(одна запись может занимать несколько блоков но не меньше одного) + 4(четыре) файла с картами (фиксированной длины, пишем по кольцу).

Алгоритм добавления записи такой:

1.Запись пишем поблочно:
  а) Обновляем карту в первом индексном файле, делаем fsync/close
  б) Обновляем карту во втором индексном файле, делаем fsync/close
  в) Пишем блок в архивный файл, делаем fsync/close.
  г) Обновляем карту в третьем индексном файле, делаем fsync/close
  д) Обновляем карту в четвертом индексном файле, делаем fsync/close

При таком раскладе вне зависимости от ФС и фазы луны в момент отключения питания у тебя всегда будет достаточно информации для того, чтобы отличить битые записи от не битых и восстановить поврежденные индексные файлы.

https://github.com/google/leveldb/blob/master/doc/log_format.txt