這 發布新的 libmdbx 庫版本 0.11.7， 發射，市場投入 項目遷移到 GitFlic 服務中脫穎而出 在 GitHub 管理部門於 15 年 2022 月 XNUMX 日刪除 libmdbx 以及其他一些項目之後，沒有任何警告或解釋，同時還阻止了與受美國製裁的公司相關的許多開發人員的訪問。
從用戶的角度來看，項目的所有頁面、repository和fork都突然變成了“404”頁面，沒有交流的可能，也沒有找出原因。
不幸的是，幾乎所有版本都丟失了，其中有很多問題都有詳細的答案，也有很多討論。 這些信息的丟失是 GitHub 管理部門設法對該項目造成的唯一客觀損害，儘管在 archive.org 檔案中仍然可以找到討論的部分副本。
內置 CI 基礎設施和腳本（對開源項目免費提供）的丟失迫使我們審查、統一和消除一點技術債務。 現在 CI 已經恢復到幾乎相同的數量（大約 100 個構建配置），除了構建和運行所有 BSD 和 Solaris 變體的測試。 引人注目的是，在 GitHub 採取行動之後，除了提醒需要付款外，沒有收到任何澄清或通知。
libmdbx 0.11.7 的主要新特性
自從最新消息發布 libmdbx v0.11.3 以來，除了從 GitHub 操作中恢復之外，還有以下改進和修復值得注意：
總共對 185 個文件進行了 89 處更改，添加了大約 3300 行， 大約 4100 個被刪除。刪除的主要原因是清除了與 GitHub 和相關服務相關的已經無用的技術文件。
新增了一個 修復在合併頁面和緩存中檢測到的不一致影響/缺陷 Linux內核中的緩衝區。 在頁面和緩衝區緩存真正統一的系統上，內核通過寫入已分配內存的文件來浪費內存在兩個數據副本上是沒有意義的。 因此，寫入的數據在 write() 系統調用完成之前通過內存分配變得可見，即使數據尚未寫入磁盤。
總而言之，其他行為是不合理的，因為使用延遲合併，您仍然必須為頁面列表捕獲鎖、複製數據或調整 PTE。 因此，自 1989 年統一緩衝區緩存出現在 SVR4 以來，一致性的潛規則就一直存在。 因此，在繁忙的 libmdbx 生產場景中發現奇怪的錯誤是一項艱鉅的工作。 首先，重現問題，然後驗證假設並檢查改進。
我們現在可以自信地說，儘管回放場景的複雜性和特殊性，問題已被可靠地識別、定位和消除。 此外，Erigon（以太坊）開發人員之一確認了繞過機制的工作，在他的案例中，在調試版本中，由於額外的斷言檢查，保護被觸發為回歸。
需要注意的是，在工作項目中廣泛使用libmdbx的背景下，從根本上來說，確保可靠運行更重要，而不是找出它是一個bug還是一個特性，以及這種一致性是否可以依賴尤其是在不尋找 Linux 內核中不一致的原因的情況下。 因此，我們在這裡討論的是解決可能影響用戶的問題。
修復了 EXDEV 錯誤的回歸 （設備之間的鏈接）當通過 API 和使用 mdbx_copy 實用程序熱複製數據庫而不壓縮到另一個文件系統時。
Kris Zyp 在 Deno 上實現了對 libmdbx 的支持。
修復了對 MDBX_opt_rp_augment_limit 選項設置的值的處理 在大型數據庫上處理大型事務時。 以前，由於存在錯誤，可能會執行不必要的操作，有時會影響以太坊實施（Erigon/Akula/Silkworm）和幣安鏈項目的性能。
修復了很多bug， 包括用於 C++ API 的那些，並修復了許多罕見和奇異配置的構建問題。 ChangeLog 上提供了所有重大改進的完整列表。
最後，如果你有興趣了解更多，可以查閱詳情 在下面的鏈接.