Здравствуйте, Sharov, Вы писали:

S>Так все операции после записи в лог. Сбой тут как помешает, если перед этим залогировались?
Все эти вещи очень хорошо разжёваны в учебниках по проектированию СУБД.
Но я попробую тезисно объяснить разницу между различными режимами протоколирования.
Давайте ещё раз рассмотрим пример с урезанием длины файла: допустим, у нас файл состоит из слова "Hello", а в транзакции делается всего лишь две операции. SetLength(0) и Write("Bye"). Предположим, мы чередуем обращения к логу и к данным, т.е. не откладываем изменения. Пишем в лог "SetLength(0)", выполняем SetLength(0), и в этот момент у нас происходит сбой. Вторая часть транзакции и её подтверждение на диск так и не попали. Вот мы "просыпаемся" после сбоя, и пытаемся восстановить целостность. У нас состояние файла данных не соответствует никакому набору применённых транзакций. Напомню: легальных состояний ровно два — "Hello" и "Bye".
Поскольку про Bye мы ничего не знаем из-за прерывания программы, нам надо как-то вернуть обратно "Hello".
Мы могли бы это сделать, изменив порядок записи: при выполнении изменений мы пишем только в лог, а сами изменения "накатываем" после commit-а. Тогда у нас будет гарантия целостности: нормальная работа программы в точности соответствует процедуре восстановления после сбоев.
Но такой подход работает только в том случае, если у нас внесение изменений не чередуется с чтениями из файла (которые могут перекрываться с результатами предыдущих изменений).
А в классическом undo-redo протоколировании мы упорядочиваем не commit и запись, а только запись в лог и запись в данные. Но оно требует сохранять при каждом изменении "старые" значения, которые мы заменяем.
Тогда при восстановлении после сбоя мы можем не только redo изменения, произошедшие в закоммиченных транзакциях, но и undo изменения, выполненные в незакоммиченных транзакциях.
В частности, в нашем случае в запись про SetLength(0) придётся добавить всё содержимое файла на момент её выполнения.
Тогда при восстановлении мы увидим, что транзакция не была завершена, и SetLength(0) будет выполнена "в обратном порядке" — мы сделаем SetLength(5) и выполним Write("Hello").

S>>С нулями не так очевидно — может быть, можно и не писать их в лог в явном виде, а обойтись сокращённой записью — типа "отсюда и досюда будут нули".
S>Setlength можно отельной записью в логе оформить и все.
Понятно, что отдельной. Но к этой записи придётся добавить значения "убранных" данных, если длина была уменьшена.

Здравствуйте, VladD2, Вы писали:

VD>Кличем был вырожденный случай Б-деревьев (нечто вроде кластерного индекса в Сиквеле).

Нафига В-дерево для read only БД?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Sharov, Вы писали:

S>>Так все операции после записи в лог. Сбой тут как помешает, если перед этим залогировались?
S>Все эти вещи очень хорошо разжёваны в учебниках по проектированию СУБД.
S>Но я попробую тезисно объяснить разницу между различными режимами протоколирования.
S>Давайте ещё раз рассмотрим пример с урезанием длины файла: допустим, у нас файл состоит из слова "Hello", а в транзакции делается всего лишь две операции. SetLength(0) и Write("Bye"). Предположим, мы чередуем обращения к логу и к данным, т.е. не откладываем изменения. Пишем в лог "SetLength(0)", выполняем SetLength(0), и в этот момент у нас происходит сбой. Вторая часть транзакции и её подтверждение на диск так и не попали. Вот мы "просыпаемся" после сбоя, и пытаемся восстановить целостность. У нас состояние файла данных не соответствует никакому набору применённых транзакций. Напомню: легальных состояний ровно два — "Hello" и "Bye".
S>Поскольку про Bye мы ничего не знаем из-за прерывания программы, нам надо как-то вернуть обратно "Hello".
S>Мы могли бы это сделать, изменив порядок записи: при выполнении изменений мы пишем только в лог, а сами изменения "накатываем" после commit-а. Тогда у нас будет гарантия целостности: нормальная работа программы в точности соответствует процедуре восстановления после сбоев.
S>Но такой подход работает только в том случае, если у нас внесение изменений не чередуется с чтениями из файла (которые могут перекрываться с результатами предыдущих изменений).

Тут про изоляцию идет речь? Путь у нас будет самая строгая, т.е. searializability (вроде еще строже есть?), но и
этот уровень сгодится.


S>А в классическом undo-redo протоколировании мы упорядочиваем не commit и запись, а только запись в лог и запись в данные. Но оно требует сохранять при каждом изменении "старые" значения, которые мы заменяем.
S>Тогда при восстановлении после сбоя мы можем не только redo изменения, произошедшие в закоммиченных транзакциях, но и undo изменения, выполненные в незакоммиченных транзакциях.
S>В частности, в нашем случае в запись про SetLength(0) придётся добавить всё содержимое файла на момент её выполнения.
S>Тогда при восстановлении мы увидим, что транзакция не была завершена, и SetLength(0) будет выполнена "в обратном порядке" — мы сделаем SetLength(5) и выполним Write("Hello").


В конкретно этом примере, почему после падения мы не сможем достать hello из лога? Ведь она как-то у нас появилось,
значит это должно быть отражено истории лога до "SetLength(0) и Write("Bye")". Если эти данные доступны, то
все просто -- последовательно с определенного момента выполняем непрошедшие операции и вроде все должно быть ок.


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

Здравствуйте, Sharov, Вы писали:

S>>Но такой подход работает только в том случае, если у нас внесение изменений не чередуется с чтениями из файла (которые могут перекрываться с результатами предыдущих изменений).
S>Тут про изоляцию идет речь?
Нет, безо всякой изоляции. Просто одна транзакция на первом этапе что-то вычисляет (и сохраняет), а на последующих — пользуется уже готовыми результатами. Типа "добавить две записи в таблицу Х", а потом "выбрать из таблицы Х все записи по критерию P". Возможно, под критерий P попадают 0, 1, или обе вставленных ранее записей.

S>В конкретно этом примере, почему после падения мы не сможем достать hello из лога? Ведь она как-то у нас появилось,
S>значит это должно быть отражено истории лога до "SetLength(0) и Write("Bye")". Если эти данные доступны, то
S>все просто -- последовательно с определенного момента выполняем непрошедшие операции и вроде все должно быть ок.
Это означает требование хранить всю историю изменений от начала времён. В типичных приложениях это чрезмерно большой объём, по сравнению с объёмом самих данных.
Плюс к этому само время восстановления после сбоя линейно растёт с накоплением изменений — а мы, естественно, хотим его ограничить чем-то разумным.
Поэтому в настоящих реализациях применяют различные механизмы усечения лога — т.н. чекпоинты.
S>В целом все понятно, но в рамках одного процесса или даже потока, работающего с файлом, особых сложностей тут быть
S>не должно.

Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Нафига В-дерево для read only БД?
А что вы предлагаете?

Здравствуйте, Sinclair, Вы писали:

НС>>Нафига В-дерево для read only БД?
S>А что вы предлагаете?

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

Здравствуйте, Sinclair, Вы писали:


S>>В конкретно этом примере, почему после падения мы не сможем достать hello из лога? Ведь она как-то у нас появилось,
S>>значит это должно быть отражено истории лога до "SetLength(0) и Write("Bye")". Если эти данные доступны, то
S>>все просто -- последовательно с определенного момента выполняем непрошедшие операции и вроде все должно быть ок.
S>Это означает требование хранить всю историю изменений от начала времён. В типичных приложениях это чрезмерно большой объём, по сравнению с объёмом самих данных.
S>Плюс к этому само время восстановления после сбоя линейно растёт с накоплением изменений — а мы, естественно, хотим его ограничить чем-то разумным.
S>Поэтому в настоящих реализациях применяют различные механизмы усечения лога — т.н. чекпоинты.

Я ровно это и написал:

с определенного момента выполняем непрошедшие операции и вроде все должно быть о

Чем это не чекпоинты? Все, конечно, хранить не надо. Начиная с какого-то момента пред. историю
можно обрезать.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Если речь про RO, то банальный сортированный список или некий персистентный аналог хеш-таблицы скорее всего будет эффективнее. B-деревья начинают играть рояль при наличии вставок единичных записей, потому что перестраивать индекс на каждую вставку в таких сценариях слишком дорого.
Интересная идея. Сортированный список будет требовать O(log2 N) чтений с диска; B-дерево — O(logB N), где B — половина размера страницы.
Хеш-таблицы — ну... может быть. Персистентные хеш-таблицы рассчитаны на внесение изменений; R/O вариант, возможно, удастся разогнать получше. Надо почитать литературу — наверняка кто-то уже таким занимался.

Здравствуйте, Sharov, Вы писали:
S>Чем это не чекпоинты? Все, конечно, хранить не надо. Начиная с какого-то момента пред. историю
S>можно обрезать.
Вас не затруднит привести алгоритм определения этого момента?

Штука тут вот в чём: если у нас лог начинается с записи "Hello" в начало файла, то мы не можем выбросить эту запись до тех пор, пока есть шанс, что какая-то другая транзакция начнёт портить это место, и не сможет дойти до коммита. То есть, до тех пор, пока у нас не будет успешной транзакции, которая меняет Hello на Bye.
В общем случае такой транзакции может не случиться никогда — это означает, что лог растёт неограниченно. Ну, либо нам придётся искать какой-то способ выполнять компрессию лога — ведь может так оказаться, что изменения, занесённые в лог после hello, уже были "заменены" следующими транзакциями, и в логе не нужны.
Компрессия лога — это ещё одно упражнение на тему целостности, которое нужно делать транзакционно. Ну, чтобы не получить два противоречащих друг другу лога. В принципе, это реализуемая задача — примерно это делается в log structured merge tree подходе. Но он применим только к определённой архитектуре СУБД — там, где мы точно можем идентифицировать отдельный элемент данных и проследить его судьбу от занесения до исключения.
Возможно, топик стартеру это и подойдёт — но работать будет совсем не так, как "транзакционная прокладка поверх файловой системы". То есть наружу будет торчать вовсе не Stream API, а API типа IDictionary<K, V>.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Sharov, Вы писали:
S>>Чем это не чекпоинты? Все, конечно, хранить не надо. Начиная с какого-то момента пред. историю
S>>можно обрезать.
S>Вас не затруднит привести алгоритм определения этого момента?

Если у нас есть снапшот (или дамп?) всех данных на какой-то момент, почему бы не обнулить историю?
1)Фиксируем корректное сост.;
2)история команд а-ля лог бд;
3)опять фиксируем корр. сост;
3.1) если все ок, то удаляем пред. историю из 2) и пишем новую.

S>Штука тут вот в чём: если у нас лог начинается с записи "Hello" в начало файла, то мы не можем выбросить эту запись до тех пор, пока есть шанс, что какая-то другая транзакция начнёт портить это место, и не сможет дойти до коммита. То есть, до тех пор, пока у нас не будет успешной транзакции, которая меняет Hello на Bye.
S>В общем случае такой транзакции может не случиться никогда — это означает, что лог растёт неограниченно. Ну, либо нам придётся искать какой-то способ выполнять компрессию лога — ведь может так оказаться, что изменения, занесённые в лог после hello, уже были "заменены" следующими транзакциями, и в логе не нужны.

1)Почему так? Это типа вечный deadlock?
2)Рано или поздно мы сможем же зафикс. корректное состояние, а далее см. алг. выше.

Здравствуйте, Sharov, Вы писали:

S>Если у нас есть снапшот (или дамп?) всех данных на какой-то момент, почему бы не обнулить историю?
S>1)Фиксируем корректное сост.;
S>2)история команд а-ля лог бд;
S>3)опять фиксируем корр. сост;
S>3.1) если все ок, то удаляем пред. историю из 2) и пишем новую.
Это неплохая идея, но она нуждается в наличии вот этого снэпшота или дампа. Как его сделать, если изменения поступают непрерывно, 24х7?
У вас нет гарантии того, что наступит такой момент, что все открытые транзакции завершились, а ни одной новой пока не поступило.
Вы, конечно, можете принудительно сделать quiescent checkpoint, временно прекратив старт новых транзакций, дождаться окончания открытых, выполнить дамп, и снова открыть базу на запись. Но это возможно не во всех сценариях.

S>>Штука тут вот в чём: если у нас лог начинается с записи "Hello" в начало файла, то мы не можем выбросить эту запись до тех пор, пока есть шанс, что какая-то другая транзакция начнёт портить это место, и не сможет дойти до коммита. То есть, до тех пор, пока у нас не будет успешной транзакции, которая меняет Hello на Bye.
S>>В общем случае такой транзакции может не случиться никогда — это означает, что лог растёт неограниченно.
S>1)Почему так? Это типа вечный deadlock?
Потому что так сложилось. Никакого deadlock. Ну представьте, что вместо записи Hello у нас там инициализация банковского счёта номер 00000001 в $0. И так получилось (случайно), что в следующие 25 лет никто этот счёт не трогал.
S>2)Рано или поздно мы сможем же зафикс. корректное состояние, а далее см. алг. выше.
Так можно делать, но это отдельный не вполне тривиальный алгоритм.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Sharov, Вы писали:

S>>Если у нас есть снапшот (или дамп?) всех данных на какой-то момент, почему бы не обнулить историю?
S>>1)Фиксируем корректное сост.;
S>>2)история команд а-ля лог бд;
S>>3)опять фиксируем корр. сост;
S>>3.1) если все ок, то удаляем пред. историю из 2) и пишем новую.
S>Это неплохая идея, но она нуждается в наличии вот этого снэпшота или дампа. Как его сделать, если изменения поступают непрерывно, 24х7?

Ну а как gc работает? Ну т.е. стоп зе ворлд, а затянувшиеся транзкации или модификации данных можно отстрелить.

S>У вас нет гарантии того, что наступит такой момент, что все открытые транзакции завершились, а ни одной новой пока не поступило.
S>Вы, конечно, можете принудительно сделать quiescent checkpoint, временно прекратив старт новых транзакций, дождаться окончания открытых, выполнить дамп, и снова открыть базу на запись. Но это возможно не во всех сценариях.

В сценарии ТС вполне может прокатить, правда сильно от данных и их размера зависит.

S>>>Штука тут вот в чём: если у нас лог начинается с записи "Hello" в начало файла, то мы не можем выбросить эту запись до тех пор, пока есть шанс, что какая-то другая транзакция начнёт портить это место, и не сможет дойти до коммита. То есть, до тех пор, пока у нас не будет успешной транзакции, которая меняет Hello на Bye.
S>>>В общем случае такой транзакции может не случиться никогда — это означает, что лог растёт неограниченно.
S>>1)Почему так? Это типа вечный deadlock?
S>Потому что так сложилось. Никакого deadlock. Ну представьте, что вместо записи Hello у нас там инициализация банковского счёта номер 00000001 в $0. И так получилось (случайно), что в следующие 25 лет никто этот счёт не трогал.

Почему в этом случае будет "это означает, что лог растёт неограниченно"?

Здравствуйте, Sharov, Вы писали:

S>Ну а как gc работает? Ну т.е. стоп зе ворлд

Это если SLA тебе стопзеворлд позволяет.

Здравствуйте, Sharov, Вы писали:

S>Ну а как gc работает? Ну т.е. стоп зе ворлд, а затянувшиеся транзкации или модификации данных можно отстрелить.
gc работает в первую очередь быстро. "Длинные паузы" в современном gc составляют десятки миллисекунд.
Вы себе представляете время создания копии пары гигабайт на диске? Причём не просто Write (как это делает Windows Explorer и любая файловая утилита), а FlushFileBuffers.

S>В сценарии ТС вполне может прокатить, правда сильно от данных и их размера зависит.
В сценарии ТС должны нормально работать практически любые встраиваемые СУБД, начиная с SQLite. К сожалению, он ничего сюда не отвечает.

S>Почему в этом случае будет "это означает, что лог растёт неограниченно"?
Потому что выбросить самую первую запись нельзя, а, значит, нельзя выбрасывать и все последующие.

Вообще, существуют же разные протоколы логгирования. Мы с вами сейчас занимаемся бессмысленной работой.
Во-первых, у нас нет данных о задаче ТС. Что за данные ему надо хранить (распределения размеров ключей и блоков данных), как он их читает, каковы соотношения между частотой записей и чтений, каковы требования по непрерывности работы и временам отклика и т.п.
Во-вторых, для различных комбинаций этих параметров есть известные решения.

А мы пытаемся придумать неизвестно что неизвестно для чего.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Sharov, Вы писали:

S>>Ну а как gc работает? Ну т.е. стоп зе ворлд, а затянувшиеся транзкации или модификации данных можно отстрелить.
S>gc работает в первую очередь быстро. "Длинные паузы" в современном gc составляют десятки миллисекунд.
S>Вы себе представляете время создания копии пары гигабайт на диске? Причём не просто Write (как это делает Windows Explorer и любая файловая утилита), а FlushFileBuffers.

Тут недостаточно данных от ТС. Но чисто теоретически можно:
1) создать копию данных в памяти;
2) сделать log resize с учетом размера данных;
3)пишем копию на диск;
4)принимаем команды на изменение состояния данных, пишем их в лог, меняем ориг. данные;

Тут есть проблема, если копия не закончилась, а какие-то изменения уже после в логе.
Как вариант, до тех пор, пока данные на задампились, принимать изменения, но не писать их в лог и\или
не сообщать результат клиенту(успех\не успех).

S>>В сценарии ТС вполне может прокатить, правда сильно от данных и их размера зависит.
S>В сценарии ТС должны нормально работать практически любые встраиваемые СУБД, начиная с SQLite. К сожалению, он ничего сюда не отвечает.
S>>Почему в этом случае будет "это означает, что лог растёт неограниченно"?
S>Потому что выбросить самую первую запись нельзя, а, значит, нельзя выбрасывать и все последующие.
S>Вообще, существуют же разные протоколы логгирования. Мы с вами сейчас занимаемся бессмысленной работой.
S>Во-первых, у нас нет данных о задаче ТС. Что за данные ему надо хранить (распределения размеров ключей и блоков данных), как он их читает, каковы соотношения между частотой записей и чтений, каковы требования по непрерывности работы и временам отклика и т.п.
S>Во-вторых, для различных комбинаций этих параметров есть известные решения.
S>А мы пытаемся придумать неизвестно что неизвестно для чего.

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

Здравствуйте, Sharov, Вы писали:

S>Тут недостаточно данных от ТС. Но чисто теоретически можно:
S>1) создать копию данных в памяти;
Сразу упираемся в предположение о том, что памяти достаточно. Иначе у нас начинается своп, т.е. то же копирование данных диск/диск, только в два приёма вместо одного.
S>2) сделать log resize с учетом размера данных;
Не очень понятно, что такое "log resize с учётом размера данных".
S>3)пишем копию на диск;
S>4)принимаем команды на изменение состояния данных, пишем их в лог, меняем ориг. данные;
S>Тут есть проблема, если копия не закончилась, а какие-то изменения уже после в логе.
Так у вас 4 выполняется после 3, или параллельно с 3?
S>Как вариант, до тех пор, пока данные на задампились, принимать изменения, но не писать их в лог и\или
S>не сообщать результат клиенту(успех\не успех).
Ну, то есть либо у нас зависает старт транзации, либо зависает commit. Хрен редьки не слаще — чем дольше мы держим транзакцию открытой, тем больше шанс, что именно в это время случится сбой и данные будут потеряны.
S>>>В сценарии ТС вполне может прокатить, правда сильно от данных и их размера зависит.
В том-то и дело, что без информации о требованиях ТС проектировать бессмысленно.

S>Полностью согласен в отсутсвии смысла подобной дискуссии ввиду отсутствия данных от ТС.
S>Некоторый академический интерес представляет дискуссия выше, уже в отвязке от пролбемы ТС.
Ну, в академическом смысле можно и пообсуждать. Но в целом тут никаких сюрпризов нет. Можно посмотреть, как устроена Transactional NTFS и либо воспользоваться ею, либо сделать так же. Но сразу же видим warning от производителя:

Microsoft strongly recommends developers utilize alternative means to achieve your application s needs. Many scenarios that TxF was developed for can be achieved through simpler and more readily available techniques. Furthermore, TxF may not be available in future versions of Microsoft Windows.

Так что можно сразу переходить к https://docs.microsoft.com/en-us/windows/win32/fileio/deprecation-of-txf

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Sharov, Вы писали:

S>>Тут недостаточно данных от ТС. Но чисто теоретически можно:
S>>1) создать копию данных в памяти;
S>Сразу упираемся в предположение о том, что памяти достаточно. Иначе у нас начинается своп, т.е. то же копирование данных диск/диск, только в два приёма вместо одного.

Согласен.

S>>2) сделать log resize с учетом размера данных;
S>Не очень понятно, что такое "log resize с учётом размера данных".

Делаем запас на снапшот(дамп), чтобы сразу после можно было писать операции изменения, параллельно с дампом.

S>>3)пишем копию на диск;
S>>4)принимаем команды на изменение состояния данных, пишем их в лог, меняем ориг. данные;
S>>Тут есть проблема, если копия не закончилась, а какие-то изменения уже после в логе.
S>Так у вас 4 выполняется после 3, или параллельно с 3?

Параллельно (см. выше).

S>>Как вариант, до тех пор, пока данные на задампились, принимать изменения, но не писать их в лог и\или
S>>не сообщать результат клиенту(успех\не успех).
S>Ну, то есть либо у нас зависает старт транзации, либо зависает commit. Хрен редьки не слаще — чем дольше мы держим транзакцию открытой, тем больше шанс, что именно в это время случится сбой и данные будут потеряны.

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

Здравствуйте, Sharov, Вы писали:

S>>>2) сделать log resize с учетом размера данных;
S>>Не очень понятно, что такое "log resize с учётом размера данных".
S>Делаем запас на снапшот(дамп), чтобы сразу после можно было писать операции изменения, параллельно с дампом.
Имеется в виду, что мы сам дамп кладём собственно в лог? А, ну да, сразу не сообразил.

S>Не совсем нравится формулировка, что у нас зависает старт транзации, либо зависает commit.
S>У нас подвисает клиент, точнее ответ ему, при этом сами мы можем принимать и обрабатывать запросы от
S>других клиентов. Не уверен что это корректно сказать, но livelock такой.
Ну всё верно — но с точки зрения клиента всё выглядит именно так. Получается, что все, у кого транзакция была начата до чекпоинта, получат повисание commit, а те, кто пробует начать транзакцию после чекпоинта, получают зависание begin tran.
Обрабатывать запросы мы можем только от тех, кто начал заранее, и всё ещё не закончил.
При большом объёме всех данных и малых объёмах изменений, это будет очень сильно заметно клиентам.

Здравствуйте, Sinclair, Вы писали:

S>>Не совсем нравится формулировка, что у нас зависает старт транзации, либо зависает commit.
S>>У нас подвисает клиент, точнее ответ ему, при этом сами мы можем принимать и обрабатывать запросы от
S>>других клиентов. Не уверен что это корректно сказать, но livelock такой.
S>Ну всё верно — но с точки зрения клиента всё выглядит именно так. Получается, что все, у кого транзакция была начата до чекпоинта, получат повисание commit, а те, кто пробует начать транзакцию после чекпоинта, получают зависание begin tran.
S>Обрабатывать запросы мы можем только от тех, кто начал заранее, и всё ещё не закончил.

Почему, у нас же есть рабочая версия, которая на момент чекпоинта изменяется? Вот все изменения ото всех
к ней и применяем. Другой вопрос, что вынуждены до конца чекпоинта ответ попридержать из-за возможной
неконсистентности.

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