The випуск нової бібліотеки libmdbx версії 0.11.7, запуску виділяється міграцією проекту на сервіс GitFlic після того, як адміністрація GitHub видалила libmdbx разом із низкою інших проектів 15 квітня 2022 року без будь-яких попереджень чи пояснень, а також заблокувала доступ багатьом розробникам, пов’язаним із компаніями, які потрапили під санкції США.
З точки зору користувача, всі сторінки, репозиторій і форки проекту раптом перетворилися на сторінку «404», без можливості спілкування та без з’ясування причин.
На жаль, майже всі версії втрачено, в якому було багато запитань з докладними відповідями, а також багато дискусій. Втрата цієї інформації є єдиною об’єктивною шкодою, яку адміністрація GitHub зуміла завдати проекту, хоча часткові копії обговорень залишаються доступними в архіві archive.org.
Втрата вбудованої інфраструктури CI та сценаріїв (доступних безкоштовно для проектів OpenSource) змусила нас переглянути, уніфікувати та усунути невелику технічну заборгованість. Тепер CI відновлено майже до того ж обсягу (близько 100 конфігурацій збірки), за винятком створення та виконання тестів для всіх варіантів BSD і Solaris. Характерно, що після дій GitHub жодних роз’яснень чи повідомлень, окрім нагадування про необхідність оплати, не надходило.
Основні нові можливості libmdbx 0.11.7
Оскільки останні новини про випуск libmdbx v0.11.3, окрім відновлення після дій GitHub, варто звернути увагу на такі покращення та виправлення:
Всього до 185 файлів було внесено 89 змін, додано приблизно 3300 рядків, було видалено приблизно 4100. Видалено в першу чергу через очищення вже непотрібних технічних файлів, пов’язаних із GitHub та залежними службами.
Додано a виправити виявлений ефект/дефект невідповідності на об’єднаній сторінці та кеші буфера в ядрі Linux. У системах, де кеші сторінок і буферів дійсно уніфіковані, ядру не має сенсу витрачати пам’ять на дві копії даних, записуючи їх у файл, який уже виділено в пам’ять. Таким чином, дані, які записуються, стають видимими через виділення пам’яті до завершення системного виклику write(), навіть якщо дані ще не були записані на диск.
Зовсім інша поведінка не є раціональною, тому що при відкладеному злиття вам все одно доведеться ловити блокування для списків сторінок, копіювати дані або налаштовувати PTE. Таким чином, негласне правило узгодженості діє з 1989 року, коли в SVR4 з’явився уніфікований буферний кеш. Як наслідок, пошук дивних помилок у напружених сценаріях виробництва libmdbx виявився великою роботою. Спочатку відтворення проблеми, потім перевірка гіпотез і перевірка покращень.
Тепер ми можемо з упевненістю сказати, що проблема була надійно ідентифікована, локалізована та усунена, незважаючи на складність і специфіку сценарію відтворення. Також роботу механізму обходу підтвердив один із розробників Erigon (Ethereum), у його випадку в налагодженій збірці захист спрацював як регрес через додаткову перевірку підтверджень.
Слід зазначити, що в контексті широкого використання libmdbx у робочих проектах принципово важливіше забезпечити надійну роботу, а не з'ясувати, чи це помилка чи особливість, і чи можна покладатися на таку узгодженість. особливо не шукаючи причин невідповідності в ядрі Linux. Отже, тут ми говоримо про вирішення проблеми, яка може вплинути на користувачів.
Виправлено регресію помилки EXDEV (зв’язок між пристроями) під час гарячого копіювання бази даних без ущільнення в іншу файлову систему, як через API, так і за допомогою утиліти mdbx_copy.
Kris Zyp реалізував підтримку libmdbx на Deno.
Виправлена обробка значення, встановленого опцією MDBX_opt_rp_augment_limit при обробці великих транзакцій у великих базах даних. Раніше через помилку могли виконуватися непотрібні дії, які іноді впливали на продуктивність реалізацій Ethereum (Erigon/Akula/Silkworm) і проектів Binance Chain.
Виправлено багато помилок, у тому числі для C++ API та виправлено багато проблем зі збіркою рідкісних та екзотичних конфігурацій. Повний список усіх суттєвих покращень доступний у ChangeLog.
Нарешті, якщо вам цікаво дізнатися більше про це, ви можете ознайомитися з деталями У наступному посиланні.