Выяснилось что утилита `mdbx_copy` и функции `mdbx_env_copy()` могут
создавать ПРОБЛЕМЫ если целевой файл расположен в encryptfs (такая
файловая система в Linux).
При этом может быть четыре исхода в зависимости от версии ядра и
положения звезд на небе:
- всё хорошо;
- плохие данные в копии без возврата ошибок;
- ошибка EINVAL(22) при копировании;
- oops или зависание ядра, отвал смонтированной encryptfs и т.п.
В текущем понимании, причина обусловлена ошибой в коде fs, которая
проявляется при использовании системного вызова `copy_file_range`.
Есть основание полагать, что mremap() может возвращать MAP_FAILED, но НЕ
устанавливать errno в некоторых пограничных ситуациях. Например, когда
системных ресурсов не хватает на актуализацию/копирование/клонирование
состояния отображения на финальной стадии, в том числе из-за раскраски
исходного отображения разными флагами через madvise().
Это решает проблему срабатывания проверочного утверждения при сборке для
платформ где тип off_t шире соответствующих полей структуры flock,
используемой для блокировки файлов.
Изменение формата LCK-файла означает что версии libmdbx использующие
разный формат не смогут работать с одной БД одновременно, а только
поочередно (LCK-файл переписывается при открытии первым открывающим БД
процессом).
1. Поле mti_unsynced_pages теперь 64-битное (чтобы не контролировать
переполнение) и перемещено для соблюдения выравнивания.
2. Поле mti_sync_timestamp переименовано в mti_eoos_timestamp
одновременно со сменой семантики. Теперь время отсчитывается не от
момента сброса данных на диск, а с момента входа в «грязное» состояние.
Скорее всего, текущая версия формата LCK не окончательная
и изменится до релиза.
При проверке использовалось глобальное значение me_dxb_mmap.current,
к которому не должны обращаться читающие транзакции. В результате,
в сложных много-поточных сценариях с изменением размера БД и её
переполнением, проверка могла выдавать ложно-положительный результат.
С точки зрения пользователя, ошибка могла проявляться как возврат
`MDBX_CORRUPTED` из читающей транзакции, когда включен "безопасный
режим" (дополнительный контроль), а в параллельной пишущей транзакции
происходит увеличение размера БД с последующим переполнением и откатом
этой транзакции. При этом никакого повреждения структуры БД нет.
Ассерт мог срабатывать из-за отсутствия бита P_LEAF2 в передаваемом проверочном значении.
На что-либо другое не влияло, но не следует понять почему этот недочет ны был выявлен тестами раньше.
В режиме MDBX_WRITEMAP с опцией сборки MDBX_AVOID_MSYNC=0 отслеживание грязных страниц не требуется.
Эта доработка устраняет еще одну из недоделок (пункт в TODO).
Ранее, при конвертации очень коротких интервалов в формат фиксированной
точки 16-точка-16, всегда выполнялось замещение нуля единицей. Т.е. если
интервал был не нулевым, но меньше 15.259 микросекунд (1/65536 секунды),
то вместо 0 возвращалось 1.
Это приводило к тому, что сумма длительности отдельных стадий нередко
была больше чем общее время фиксации транзакции. Проблема усугублялась,
если получаемые значения аккумулировались по серии транзакций.
Теперь такая защита от нуля выполняется только для общего времени,
но не для отдельных стадий.
Было:
latency(ms): preparation=72.69 gc=72.69 write=73.04 sync=141.40 ending=72.69 whole=142.14
Аккумулированная сумма длительности этапов ВТРОЕ(!) больше общей длительности.
Стало:
latency(ms): preparation=0.00 gc=0.02 write=0.79 sync=67.98 ending=0.00 whole=140.81
Аккумулированная сумма длительности этапов меньше общей длительности,
так как для каждой транзакции общая длительность возвращается не менее 15.259 микросекунд.
