Новый ГодReciprocatedНапоминаю задачу: нет задачи гарантированно записать данные. Есть задача оставить файл в консистентном состоянии, т.е. можно записать кусок кала, но при поднятии достать все старые данные и понять, что этот кусок является плохим.

Текущее простое и сердитое решение, которое вроде бы это гарантирует.
Кто считает, что не гарантирует - скажите конкретно где и почему.

запись
- хотим дописать 76 кб данных
- добавляем в конец файла header постоянного размера, в который пишем hash данных + размер данных (76*1024) + hash самого header перед ним.
- вызываем fsync() -- это как барьер памяти, не позволяющий переупорядочить операции записи перед ним и за ним
- дописываем наши данные
- вызываем fsync()

чтение после сбоя
1. если header в неадеквате (файл кончился раньше размера header (он фиксир.), hash хидера не совпало) - считаем всё пространство файла далее пустым
2. если header вменяем, но в файле осталось меньше данных чем сказано в header или данных хватило, но их HASH не совпал с указанным в header - пункт (1) - считаем файл пустым, начиная с начала header
можно тупо размер файла хранить где-то дополнительно
скажем в заголовке файла или в отдельном месте
после записи куска данных в файл апдейтить этот размер
что <= размера то в консистентном состоянии
что > размера -- это кусок кала
Хотелось бы кализировать только не записавшуюся часть файла, а не все ранее накопленные данные.

Новый ГодReciprocatedпропущено...

1. Ок
2. Я не юзаю промежуточных буферов, сразу отправляю данные OS через ::write(), мне одного fsync() хватит
3. Не понял что вы хотите, если задача успешно вроде бы решена. Как хотите - можете поставить себе задачу придумать такую структуру данных и алгоритм, которые работают через запись в середину, тогда и разгребайте грабли сами и описывайте алгоритм. Решение с дописыванием в конец header + data решило задачу, я обошёлся без необходимости что-то ворочать в середине. Но если очень хочется - условия это не запрещают. Лишь бы новые данные каким-то образом консистентно добавились в хранилище без утечки "дисковой памяти" и с возможностью половинчатые записи потом увидеть.
ниче не решило
твой хеадер может теоретичнски являться куском кала
просто у них структура чудесным образом совпала
Хедер кусок кала - это описано в предусмотрениях.

Новый ГодReciprocatedпропущено...

Хотелось бы кализировать только не записавшуюся часть файла, а не все ранее накопленные данные.



ну так и есть же, вроде все правильно
кусок данных в файле до size -- валидный
или ты нам че-то недоговариваешь
Всё. Теперь понял.

Новый ГодReciprocatedпропущено...

Хедер кусок кала - это описано в предусмотрениях.

ты его с какого-то перепуга в конец пишешь а потом данные
как после сбоя ты определяешь по какому смещению у тебя header?
Header предваряет каждую запись. Header-ов в файле много.
Открываю файл с начала и пробегаю до последнего валидного header (или до конца файла).
Файл как лента стриммерная. Шашлык из валидных записей. Как только попался горелый кусок мяса - остальное фтопку.

Новый ГодReciprocatedпропущено...

Всё. Теперь понял.

если у тебя не абстрактный файл а какой-то свой,
я бы заголовок в начале сделал, и в нем поле с последним валидным размером данных
Головой seek-ать дорого по времени.