C++: атомарно добавить в файл 128MB данных.

скопировать файл, добавить в него, затем mv поверх старого,

но если у тебя файл большой, или добавлять часто то есесно это не выход

Следи за хешем файла (или его частей), как вариант.

Возможно, стоит посмотреть в сторону конфига размеров страницы и когерентности mmap (не уверен что оно так умеет).

Если контролируешь формат файла - проще и надёжнее писать блоками с контрольными суммами.

Ну и кстати. Причём тут c++?

В конец данных добавляешь SHA1.

Ну и кстати. Причём тут c++?

Для привлечения внимания пытливых умов, хипстеры-то на вопрос не ответят.

Если контролируешь формат файла - проще и надёжнее писать блоками с контрольными суммами.

А как писать блоками? Как определить размер блока, который запишется атомарно? И писать видимо обязательно с позиций кратных размеру блока?

В конец данных добавляешь SHA1.

Начал писать 128MB (вызвал write(fd, buff, 128MB)), наполовине питалово сдохло, HDD успел дописать какой-то сектор и помер.

Потом начинаю читать файл - а там в конце какая-то херь и SHA1 нету. Как определить, что это херь?

Кури технику записи wal в субд.

Делай сначала append, потом fsync. Если все прошло удачно, в заголовке обнови указатель на новые данные

потом fsync

потом fdatasync(3), а потом ещё хорошенько помолиться :)

Если нужно совсем надёжно, то новый файл + rename(3).

Именно поэтому ты решил поставить хипстерский тег?

Для винчестера атомарный блок это сектор 512 байт. Для флешнакопителей без понятия, может кто просветит?

Как определить, что это херь?

Используй SHA1.

потом fdatasync(3), а потом ещё хорошенько помолиться :)

Нафиг fdatasync? fsync возвращается после физической записи буфера для данного дескриптора на диск. Что ещё нужно сверх того? А молиться почему?

Используй SHA1.

У тебя sha1 в конце, он не дописался. У тебя в конце непонятный кусок мусора с неизвестным размером и без sha1 - его даже перешагнуть невозможно, весь файл считай кончился.

Не, писать блоками кратными степени двойки желательно но необязательно. Пишешь примерно так: в основной, а лучше в индексный файл - номер блока и контрольная сумма.

Размер блока видимо размер страницы mmap.

Не, писать блоками кратными степени двойки желательно но необязательно

Что даст именно степень двойки? Любая запись больше 1 сектора уже опасна, поэтому писать надо имено сектор по-моему.

Из этого ты можешь сделать вывод, что файл не дописался, и поступать как сам сочтешь нужным - игнорировать мусор, открывать WAL, писать письма пользователю или что-то еще.

Размер блока видимо размер страницы mmap.

Никакой связи.

Почему? Разве mmap не постранично сбрасывает на диск?

Это если ты хочешь всё руками реализовать а не на откуп ОС отдать. А руками тебе дисковые кэши скорее всего всё равно не дадут, если ты не из ядра писать будешь.

Размер блока ФС, блока устройства, и размер страницы в общем случае не связаны (окей, блок ФС _обычно_ равен странице, но не всегда).

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

Просто сброс страницы вроде как атомарный в mmap

Ничего не знаю об атомарности mmap.

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

Считаться кем? ФС всё равно.

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

Журнал для данных есть в ext3/4, но рукожопые китайцы умеют делать винты, которые рапортуют ОК, когда данные попали в кеш винта, а не на диск.

Так что только усердными молитвами мы сможем сохранить наши данные :)

Из этого ты можешь сделать вывод, что файл не дописался, и поступать как сам сочтешь нужным - игнорировать мусор, открывать WAL, писать письма пользователю или что-то еще.

Из чего «этого»? Я незнаю, дописался он или нет. Вначале блока у тебя нет размера этого блока...

fsync возвращается после физической записи буфера для данного дескриптора на диск

Ха-ха-ха! Нет.

https://lwn.net/Articles/457667/

Алсо тебе никто не гарантирует, что данные не осядут в кэше диска.

Кеш диска гарантированно дописывается при подрыве питания. Вроде. И неясно как тебе поможет fdatasync(), если fsync() не помогает. fdatasync() есть просто урезанная версия fsync(), которая типа дату модификации файла не пишет. Но fsync() уж точно делает всё, что делает fdatasync(). При том, где-то я читал, что современный линукс эти 2 функции одинаково выполняет абсолютно, т.е. fdatasync() апдейтит время модификации файла, насрав на спеку.

Короче, не убедил )

Из чего «этого»?

Из несовпадения SHA1 с содержимым.

Я незнаю, дописался он или нет. Вначале блока у тебя нет размера этого блока...

Ты вроде спрашивал, как записать 128М, а сейчас не знаешь размер блока?

Кеш диска гарантированно дописывается при подрыве питания. Вроде.

Гарантированно и вроде в одном предложении - это прекрасно.

И неясно как тебе поможет fdatasync(), если fsync() не помогает.

Никак не поможет. Я лишь указал на то, что fsync() скорее всего не будет достаточно.

Ты вроде спрашивал, как записать 128М, а сейчас не знаешь размер блока?

Да, блок произвольного размера :)

Никак не поможет. Я лишь указал на то, что fsync() скорее всего не будет достаточно.

Не, я не спорю. Просто хочу конструктива. Какие есть ещё варианты? По-поему картинка выглядит так: fsync() кладёт данные максимально хардварно, и да это может означать кеш диска. Но дисковый аппаратный кеш на запись может быть, исходя из здравого смысла, ограничен способностью диска при обрыве питания дописать это всё на винт. Иначе получится ситуация, когда при работающем оборудовании никто ничего не гарантирует, а это уже лютый бред. Поэтому у меня вот такая картинка, в котором fsync() оказывается железно достаточно, если диск не рехнулся.

вообще ИБП спасает.... тем более если промышленное применение твоей системы. А так - могу посоветовать только смотреть в сторону контроллера с flash-backend buffer, который при пропадании питания сбросит кеш записи на флеш и только потом отключится. Причем контроллер(ы) желательно выделить отдельно под задачу, если уж данные такие важные.

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

Это суровая реальность.

Значит, добавь размер.

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

Это суровая реальность.

Твоя реальность как-то с реальной реальносью расходится, ведь даже обычные СУБД данных вообще не теряют при любом расколбасе питания, пока диск физически нормален.

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

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

Да, отлично, всё так.

чтобы это переживало отрубание питалова в любой момент

глюпий, может и пожар должно пережить? а ваще, кури транзацкии.

глюпий, может и пожар должно пережить? а ваще, кури транзацкии.

Инна, изабелла.

ведь даже обычные СУБД данных вообще не теряют при любом расколбасе питания, пока диск физически нормален.

http://blog.nordeus.com/dev-ops/power-failure-testing-with-ssds.htm

Правда не теряют?

Там описаны сбои дисков, а не СУБД.

Там описаны сбои дисков, а не СУБД.

Да, и? Это что-то меняет? Чувак утверждает, что СУБД магическим образом пишут на диск так что данные не теряются.

https://ru.wikipedia.org/wiki/TTH

Правда не теряют?

Д

Да, и? Это что-то меняет? Чувак утверждает, что СУБД магическим образом пишут на диск так что данные не теряются.

Чувак этого не утверждал. Магии не существует. Чувак утверждал, что на исправном оборудовании есть способы гарантированно не просрать данные. Мы не рассматриваем случаи неисправного оборудования.

Мы не рассматриваем случаи неисправного оборудования.

Ты по ссылкам вообще ходишь? Там чуваки тестировали новые SSD.

Скажем, если размер атомарной записи = 512 байт

Для очень старых дисков нужен алгоритм? Уже давненько физический минимум 4096 байт. А 512 байт - это только для совместимости.

fsync() кладёт данные максимально хардварно, и да это может означать кеш диска.

А может означать пустышку. В зависимости от того, как настроена конкретная система (см. ссылку на lwn выше). Т.е. твоя прога обязана предупредить пользователя (а он, в свою очередь, администратора), чтобы он принял все от него зависящие меры.

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

Возьмём диск с кешем 128 МБ. Представим, что записывать надо в конец, где скорость уже около 60-70 МБ/с. Отрубаем питание - и? Он явно не продолжает работать в течение почти 2 секунд, а мгновенно паркует головки. Или кому-то встречался диск с буфером в виде суперконденсатора или чего-то подобного?

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