SQLite 与 OpenAFS 锁定兼容吗？

Question

我希望许多联网计算机上的许多进程同时通过 OpenAFS 1.4.12.1 访问同一个 SQLite 数据库。写入不会频繁，因此 SQLite 的单次写入设计应该不会有问题。

我想知道这是否可行。我无法找到两个关键信息：

SQLite 文档 指出“SQLite 使用 POSIX Advisory locks 在 Unix 上实现锁定”。它还警告“最好的防御是不要对网络文件系统上的文件使用 SQLite”。然而，它似乎没有指定 SQLite 是否仅使用整个文件锁定，或者是否也使用字节范围锁定。

我也无法找出 OpenAFS 1.4.12.1 支持哪些类型的锁定。不幸的是，这个1998年的非官方来源是我最好的来源已经能够找到了。当时，支持整个文件锁定，但不支持字节范围锁定。

官方文档只显示此页面，尽管标题很友好，但实际上并没有说明是否最新的 OpenAFS 支持 POSIX 字节范围咨询锁定。

编辑： 这有可能吗？如果是这样，是否需要任何编译时 SQLite 标志？

Answer 1

我已经使用 SQLite 相当长一段时间了，并且有幸处理过一些锁定问题。我非常确定 SQLite 默认情况下在 Unix 文件系统上使用字节范围锁。

更准确地说，它包含一些替代锁定方法的代码（例如使用 flock() 和 dotlock-style 整个文件锁）。当使用SQLITE_ENABLE_LOCKING_STYLE选项编译时，它会尝试自动检测正确的底层文件系统的锁定方法。

自动检测代码包含一些硬编码的情况（例如“ufs”、“nfs”和“smbfs”），其中没有一个是AFS。如果没有硬编码的大小写匹配，SQLite 会尝试使用 fcntl()。然后，它假设如果 fcntl() 调用成功，则字节范围锁可用。

这就是 OpenAFS 让事情变得有趣的地方。显然（[1]，[2], [3]) OpenAFS 在字节范围锁方面向用户空间应用程序撒谎的历史悠久。来自openafs-1.4.14源代码：

/* next line makes byte range locks always succeed,
 * even when they should block */
if (af->l_whence != 0 || af->l_start != 0 || af->l_len != 0) {
    DoLockWarning();
    afs_PutFakeStat(&fakestate);
    return 0;
}

一句话：哎呀！

无论如何，它都允许字节范围锁定成功。在 Linux 上，情况可能更糟：它使用内核基础设施在同一系统的进程之间提供字节范围锁。这意味着应用程序不能只是分叉一个新进程并测试锁定机制 - 字节范围锁看起来工作正常，但在保护文件免受远程进程侵害方面却严重失败。

简而言之：您无法通过 OpenAFS 可靠地使用未经修改的 SQLite。大多数其他网络文件系统也存在问题，因此建议完全避免使用网络文件系统。

一些可能的解决方法（排名不分先后）：

• 使用适当的 DBMS，例如 PostgreSQL。如果可以做到这一点，从长远来看，您的情况会更好。

• 如果成熟的 DBMS 太过分了，请为您的应用程序实现您自己的服务器。

• 修改 SQLite 源代码以默认为 OpenAFS 上的 flock()。我不确定这是否能正常工作，因为 OpenAFS 有着悠久的历史 ([1]、[2] ）的锁定问题，即使使用普通的 flock()，但在测试之前您不会知道。

• 使用 OpenAFS 用户空间，而不是通过内核，为 SQLite 实现您自己的 OpenAFS VFS。

• 用另一个网络文件系统试试你的运气。

无论您做什么，如果以任何方式涉及 SQLite3 和共享数据库文件，您都必须执行大量测试。

编辑：

评论者建议使用点锁文件机制。我没有深入研究 OpenAFS 源代码，但乍一看它似乎支持 < code>open(O_CREAT|O_EXCL) 创建 SQLite 使用的点锁文件的方法。如果这按预期工作，那么如果您强制 SQLite 使用点锁方法，那么 SQLite 可能确实可以与 OpenAFS 一起使用。

也就是说，点锁在常规本地文件系统上已经足够成为一个问题，而无需将网络文件系统的复杂性引入其中 - 这就是为什么我一开始没有建议它。