A az új libmdbx könyvtár 0.11.7 verziójának kiadása, az indítás kiemelkedik a projektnek a GitFlic szolgáltatásba való áttelepítésével miután a GitHub adminisztrációja 15. április 2022-én minden figyelmeztetés és magyarázat nélkül eltávolította a libmdbx-et számos más projekttel együtt, miközben számos olyan fejlesztőt is blokkolt, amelyek az Egyesült Államok szankciói alá eső vállalatokkal kapcsolatban állnak.
A felhasználó szemszögéből a projekt összes oldala, tárháza és forkjai hirtelen „404-es” oldallá változtak, kommunikációs lehetőség nélkül és az okok kiderítése nélkül.
Sajnos szinte minden verzió elveszett, amelyben sok kérdés volt részletes válaszokkal, valamint sok vita. Ennek az információnak az elvesztése az egyetlen objektív kár, amelyet a GitHub adminisztrációjának sikerült okoznia a projektben, bár a megbeszélések részleges másolatai továbbra is elérhetők az archive.org archívumban.
A beépített CI infrastruktúra és a szkriptek elvesztése (amelyek ingyenesen elérhetők az OpenSource projektek számára) arra kényszerítettek bennünket, hogy felülvizsgáljuk, egységesítsük és felszámoljunk egy kis technikai adósságot. A CI-t mostanra majdnem ugyanarra a mennyiségre állítottuk vissza (körülbelül 100 összeállítási konfiguráció), kivéve az összes BSD és Solaris változat építési és futtatási tesztjeit. Sokatmondó, hogy a GitHub intézkedései után a fizetés szükségességére való emlékeztetőn kívül nem érkezett felvilágosítás vagy értesítés.
A libmdbx fő újdonságai 0.11.7
A libmdbx v0.11.3 kiadásával kapcsolatos legfrissebb hírek óta a GitHub-műveletekből való helyreállításon túl a következő fejlesztéseket és javításokat érdemes megjegyezni:
Összesen 185 módosítás történt 89 fájlban, hozzávetőleg 3300 sor került hozzáadásra, körülbelül 4100 eltávolításra került. Elsősorban a GitHubhoz és a függő szolgáltatásokhoz kapcsolódó, már használhatatlan technológiai fájlok törlése miatt.
Hozzáadva a az egyesített oldalon és a gyorsítótárban észlelt következetlenségi hatás/hiba javítása a pufferből a Linux kernelben. Azokon a rendszereken, ahol az oldal és a puffer gyorsítótár valóban egységes, nincs értelme, hogy a kernel két adatmásolatra pazarolja a memóriát azzal, hogy egy már memórialefoglalt fájlba ír. Ezért a megírt adatok láthatóvá válnak a memóriafoglaláson keresztül, mielőtt a write() rendszerhívás befejeződik, még akkor is, ha az adatok még nem kerültek lemezre.
Összességében más viselkedés nem racionális, mert a késleltetett egyesítésnél továbbra is le kell zárni az oldallistákat, másolni kell az adatokat, vagy módosítani kell a PTE-ket. Így a konzisztencia kimondatlan szabálya 1989 óta érvényben van, amikor is megjelent az egységes puffer gyorsítótár az SVR4-ben. Ennek eredményeként a furcsa hibák felkutatása a forgalmas libmdbx gyártási forgatókönyvekben sok munka volt. Először a probléma reprodukálása, majd a hipotézisek ellenőrzése és a fejlesztések ellenőrzése.
Most már magabiztosan kijelenthetjük, hogy a problémát a lejátszási forgatókönyv bonyolultsága és sajátossága ellenére megbízhatóan azonosították, megtalálták és eltávolították. Valamint a bypass mechanizmus működését az Erigon (Ethereum) egyik fejlesztője is megerősítette, az ő esetében a debug buildben a védelem regresszióként aktiválódott egy további érvényesítési ellenőrzés miatt.
Megjegyzendő, hogy a libmdbx széles körben elterjedt munkaprojektekben való alkalmazása kapcsán alapvetően fontosabb a megbízható működés biztosítása, nem pedig annak kiderítése, hogy hiba vagy szolgáltatás, és hogy lehet-e támaszkodni az ilyen következetességre. különösen anélkül, hogy a Linux kernelen belüli inkonzisztencia okait keresnénk. Tehát itt egy olyan probléma megoldásáról beszélünk, amely érintheti a felhasználókat.
Javítva az EXDEV hiba regressziója (eszközök közötti kapcsolat), amikor egy adatbázist tömörítés nélkül másol egy másik fájlrendszerbe, mind az API-n keresztül, mind az mdbx_copy segédprogrammal.
Kris Zyp bevezette a libmdbx támogatását a Denon.
Az MDBX_opt_rp_augment_limit opció által beállított érték javítása nagyméretű tranzakciók feldolgozásakor nagy adatbázisokon. Korábban egy hiba miatt szükségtelen műveletek hajthatók végre, ami néha befolyásolta az Ethereum implementációk (Erigon/Akula/Silkworm) és a Binance Chain projektek teljesítményét.
Sok hibát javítottak, beleértve a C++ API-hoz tartozókat is, és számos felépítési problémát javított a ritka és egzotikus konfigurációkon. Az összes jelentős fejlesztés teljes listája elérhető a ChangeLog-ban.
Végül, ha többet szeretne tudni róla, tájékozódhat a részletekről A következő linken.