我知道 SQLite 在具有多个客户端的共享文件系统上并不理想。但是，文档暗示多个阅读器应该没问题。
我的 SQLite 数据库驻留在 Lustre 卷上，并且数据库是“分区的”——尽管它是一个VIEW，而不是显式表，使用 ID 上的模运算符来定义分区——这样多个读取器是互斥的。这可行，但在（传闻中）大约 40% 的时间里，我在读取数据库时收到“磁盘 I/O 错误”（使用 Python 3.7.4 和 SQLite 3.30.0，使用 Python stdlib sqlite3）。
假设标准 Unix VFS 的假设不适用于 Lustre 文件系统（因为它们不适用于其他网络文件系统）是否安全？如果是这样，为什么它对读者很重要？
假设我只需要使用 Lustre 上的 SQLite，我能做些什么来缓解这种情况吗？例如，将数据物理分离到多个 SQLite 分片中，这些分片永远只有一个客户端，并且可能会将ATTACH它们发送到中央源？
您没有提到您使用的是哪个版本的 Lustre，这很重要。假设您的服务器版本至少为 2.5 或更高版本，我建议客户端使用 Lustre 2.12.3（或更高版本），因为这解决了许多性能和功能问题。特别是，它flock默认启用，这通常是在用户空间中的应用程序之间共享文件的要求（否则，使用-o flockmount 选项挂载客户端）。通常需要该flock功能来确保对同一文件的多次读取/写入是一致的。
Lustre 本身在客户端之间是完全缓存一致的，并且几乎完全符合 POSIX（与本地 ext4 文件系统相同，除了 atime 更新等少数例外），这是它广泛用于并行应用程序的原因之一。与 NFS 不同，它对于同一文件上的多个写入器/读取器没有一致性问题。
至于 IO 错误，首先要问的是应用程序在做什么样的 IO（buffered or O_DIRECT）？ 对于O_DIRECT非古代内核，读/写需要调整大小/内存与磁盘的逻辑块大小（可能是 4096 字节或更高的二次幂）对齐，所以它不能做 512 字节大小O_DIRECT。使用 Lustre 绝对可以在同一个文件上同时进行写入和读取操作，但是如果客户端在同一个块上竞争，这将导致更高的延迟。
其次，当 SQLite 报错时，您是否在客户端或服务器的控制台上收到任何错误？在运行应用程序时检查行的或行的dmesg输出。/var/log/messagesLustreError: