Есть файл 512MB, хочется атомарно дописать туда 128MB. Атомарно - значит что после


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

Дописать - не значит обязательно в конец и не значит, что одним последовательным куском. Можно заранее выделять в файле место и манипулировать страницами внутри. Как в любой файловой системе (fat32, ext3, ext4, другое) определить параметры атомарной записи? Вмысле, с какого смещения и сколько байт в файл записать, чтобы это гарантированно было атомарно? Например, предполагаю, что со смещений кратных 4096 писать размер блока 4096 - вполне атомарно для современных дисков с сектором 4096 байт, ибо файловая система кладёт файлы выравнивая их по секторам.

Обсудите сабж. Предложите простейшую структуру данных в файле и алгоритм для обеспечения сего.
P.S. Знаю про double buffering например, который вроде бы в InnoDB юзается: пишем последовательность страниц в этот буфер, делаем fsync(), потом поднявшись после падения достаём из этого буфера что там есть и распихиваем по месту назначения, делая fsync и очищая потом временный буфер. Но вопрос о размере атомарного блока остаётся.

Dimitry SibiryakovReciprocatedКак в любой файловой системе (fat32, ext3, ext4, другое) определить параметры атомарной
записи?

Никак, обломись. Для журналируемых систем есть соответствующие API, но для каждой - своё
отдельное. Для остальных - просто обломись.

Мне не нужны функции журналируемой ФС.

alexy_black если упало питание - это кранты. никакие программные примочки тебе не помогут. только если файл создать новый, потом перименовать. так поступают базы данных.
сама файловая система после ткого збоя будет востанавливать данные. то есть ты не можешь такого гарантировать даже на нулевом кольце.
Мужики-то не знали... особенно такие мужики:
- которые сделали диски, дописывающие кеши после отрубания питалова
- которые придумали WAL
- которые придумали double buffering

Как же тогда работают журналы в журналируемых ФС, сохраняя структуру этих ФС после всех отрубаний питалова.

Владимир2012Alternatives to using Transactional NTFS https://msdn.microsoft.com/en-us/library/windows/desktop/hh802690(v=vs.85).aspx

" It allows for Windows developers to have transactional atomicity for file operations in transactions with a single file, in transactions involving multiple files, ..."
Маркетинг буллшит. Не переходить же на другую ФС, если можно просто узнать размер блока и юзать fsync().

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

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

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

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

Dimitry SibiryakovReciprocatedМне не нужны функции журналируемой ФС.

Тогда не выпендривайся и используй атомарный rename. Или обломись.

Чё-то ты не можешь отличить журнал ФС от журнала моего файла...

SiemarglDimitry Sibiryakovпропущено...

Тогда не выпендривайся и используй атомарный rename. Или обломись.

+1

Тема не относится к С++ и к конструктивному обсуждению.

Предлагаю автора с темой вернуть в ПТ.
К С++ не относится, C++ тут как кейворд привлечения пытливых умов, ибо толпы тусующиеся вокруг других ключевых слов менее вероятно чё-нибудь дельное напишут.

Модератор: Тема перенесена из форума "C++".

Новая версия алгоритма.

запись
- пример: хотим добавить 76 кб данных
- добавляем в конец файла header фиксированного размера, в который пишем hash данных + размер данных (76*1024). Можно записать hash этого header прямо перед ним самим
- дописываем наши данные (76 kb payload)
- вызываем fsync() - как барьер памяти. Порядок записи header1 и data1 неважен, лишь бы отделить эту пару от header2 и data2.

чтение после сбоя
1. Открываем файл сначала и последовательно проверяем: если очередной header в неадеквате (файл кончился раньше размера header (он фиксир.), hash header-a не совпало) — считаем всё пространство файла начиная с header-а далее пустым. Потеряем только 1 запись, ведь в середине ничего не переписывали.
2. если header вменяем, но в файле осталось меньше данных чем сказано в header или данных хватило, но их hash не совпал с указанным в header - пункт (1) - считаем файл пустым, начиная с начала header

Вася УткинReciprocatedНовая версия алгоритма.

запись
- пример: хотим добавить 76 кб данных
- добавляем в конец файла header фиксированного размера, в который пишем hash данных + размер данных (76*1024). Можно записать hash этого header прямо перед ним самим
- дописываем наши данные (76 kb payload)
- вызываем fsync() - как барьер памяти. Порядок записи header1 и data1 неважен, лишь бы отделить эту пару от header2 и data2.

чтение после сбоя
1. Открываем файл сначала и последовательно проверяем: если очередной header в неадеквате (файл кончился раньше размера header (он фиксир.), hash header-a не совпало) — считаем всё пространство файла начиная с header-а далее пустым. Потеряем только 1 запись, ведь в середине ничего не переписывали.
2. если header вменяем, но в файле осталось меньше данных чем сказано в header или данных хватило, но их hash не совпал с указанным в header - пункт (1) - считаем файл пустым, начиная с начала header
1. Должно работать. Если файл увеличен заранее - выделены кластеры и замаплены на сектора, то и ошибок файловой системы не должно быть.
2. Почему не std::fstream::flush ?
3. И что стало в условияем? "Дописать - не значит обязательно в конец и не значит, что одним последовательным куском."
1. Ok. Полезно выделить заранее кусман...
2. Не знал про такое, не важно как именно fsync() дёрнуть
3. Это не условие, а дозволение - оно есть по-прежнему.

Bred eFeMReciprocated, 19649369 , 19649465 классная штука и должна работать, а на ntfs можно заюзать и файловые потоки.

Только теперь нужно подумать как "атомарно" увеличить размер файла и как "атомарно" записать header.

--
А может просто после каждой небольшой порции писать этот header(ECC,CRC).
О, а диски у себя в патрохах так и делают!

Так что rename.bak и/или write.log очень даже ФС независимо.
Атомарно размер файла увеличивать не надо.
Атомарно записывать header не надо.

Вася УткинReciprocatedпропущено...

1. Ok. Полезно выделить заранее кусман...
2. Не знал про такое, не важно как именно fsync() дёрнуть
3. Это не условие, а дозволение - оно есть по-прежнему.
1. Ошибки ФС могут быть только при изменении размера файла, при условии, что сжатие в ФС отключено.
2. Возможно понадобятся оба: обязательно OS fsync() и возможно C++ flush() : http://stackoverflow.com/questions/2340610/difference-between-fflush-and-fsync/2340641#2340641
Например, так: http://stackoverflow.com/questions/676787/how-to-do-fsync-on-an-ofstream
3. А тут надо уточнить, "не значит обязательно в конец" - это значит перезаписывать середину, или сначала сдвигать все последующие блоки, а затем писать в свободную середину?
1. Ок
2. Я не юзаю промежуточных буферов, сразу отправляю данные OS через ::write(), мне одного fsync() хватит
3. Не понял что вы хотите, если задача успешно вроде бы решена. Как хотите - можете поставить себе задачу придумать такую структуру данных и алгоритм, которые работают через запись в середину, тогда и разгребайте грабли сами и описывайте алгоритм. Решение с дописыванием в конец header + data решило задачу, я обошёлся без необходимости что-то ворочать в середине. Но если очень хочется - условия это не запрещают. Лишь бы новые данные каким-то образом консистентно добавились в хранилище без утечки "дисковой памяти" и с возможностью половинчатые записи потом увидеть.