这 发布新的 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 上提供了所有重大改进的完整列表。
最后，如果你有兴趣了解更多，可以查阅详情 在下面的链接.