SQLite 与 OpenAFS 锁定兼容吗？

Question

我想让许多联网计算机上的许多进程通过 OpenAFS 1.4.12.1 同时访问同一个 SQLite 数据库。写操作会很少，所以SQLite的单写设计应该不是问题。

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

SQLite documentation声明“SQLite 使用 POSIX 建议锁来实现 Unix 上的锁定”。它还警告说“你最好的防御是不要对网络文件系统上的文件使用 SQLite”。但是，它似乎没有具体说明 SQLite 是否只使用整个文件锁定，或者它是否也使用字节范围锁定。

我也无法确定 OpenAFS 1.4.12.1 支持哪些类型的锁定。这unofficial source from 1998不幸的是，这是我能找到的最好的来源。那时，支持整个文件锁定，但不支持字节范围锁定。

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

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

Answer 1

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

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

自动检测代码包含一些硬编码的情况(例如“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 上，情况可能更糟:它使用内核基础结构在同一系统的进程之间 提供字节范围锁。这意味着应用程序不能只派生一个新进程并测试锁定机制 - 字节范围锁似乎工作正常，但无法保护文件免受远程进程的影响。

简而言之:您不能将未修改的 SQLite 可靠地用于 OpenAFS。大多数其他网络文件系统也有问题，因此建议完全避免使用网络文件系统。

一些可能的变通方法(排名不分先后):

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

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

• 修改 SQLite 源代码以默认为 OpenAFS 上的 flock()。我不确定这是否会正常工作，因为 OpenAFS 有很长的锁定问题历史([1]，[2])，即使是普通的 flock()，但你不会知道直到您对其进行测试。

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

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

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

编辑:

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

也就是说，在不将网络文件系统的复杂性引入混合的情况下，点锁在常规本地文件系统上就足够了 - 这就是为什么我一开始没有建议它。