当cache=loose运行一个可写的9pfs共享是可以的吗？

Question

我试图在可写的9p根文件系统上运行虚拟机。当使用默认缓存模式时，apt和其他一些工具会失败；可能是由于9 9pfs本身的限制。apt产生的错误消息是：

Apt: Unable to determine file size for fd ... : No such file or directory

在线快速搜索建议，在挂载文件系统时，我应该将缓存设置为loose。在我的系统上挂载带有cache=loose的文件系统确实允许我正常使用apt。

但是，现在我担心文件系统的一致性。内核文档指出，这个cache=loose只适用于只读系统，但遗憾的是没有进一步详细说明。

因此，我提出以下问题:如果我只通过设置为松散缓存的单个挂载点访问文件系统，并且不访问文件系统或其底层目录，那么我会面临任何一致性/一致性问题吗？

或者用另一种方式说明:当只从一个挂载点单独查看文件系统时，松散缓存是否会影响文件系统的一致性？

我使用以下挂载选项:内核命令行中的rw,trans=virtio,version=9p2000.L,cache=loose和fstab。

Answer 1

在9p.txt还有另一个https://landley.net/kdocs/Documentation/filesystems/9p.txt文档，它专门列出了一些缓存模式和其他项目。

看来，如果您访问一个系统，那么缓存不应妨碍您的活动。它只是，9p将不会推动任何修改从一个客户端到任何其他安装相同份额。他们只会在下一个请求中看到新的更新。

除了前两段之外，这另一份文件基本上是你所链接的那份文件的替代品。为了正确地设置挂载点，可能应该阅读这两个文档来理解您想要做的事情。下面只是缓存模式部分的重发，以供快速浏览参考。

CACHE MODES
===========

By default, 9p operates uncached, letting the server handle concurrency.
On a modern LAN this as fast or faster than talking to local disk,
and scales surprisingly well (about as well as web servers). Back before
cache support was even implemented, v9fs was tested with ~2000 simultaneous
clients running against the same server, and performed acceptably. (Run
the server as root so setrlimit could remove the per-process filehandle
restriction, give server had plenty of RAM and plug it into a gigabit
switch.)

The "-o cache=loose" mode enables Linux's local VFS cache but makes no attempt
to handle multi-user concurrency beyond not panicing the kernel: updates are
written back when the client's VFS gets around to flushing them, last writer
wins. File locking and fsync/fdatasync are available if an application wants
to handle its own concurrency. Loose cacheing works well for read-only
mounts (allowing scalable fanout in clusters with intermediate servers
re-exporting read-only v9fs mounts to more clients), or mounts with
nonconcurrent users (including only one client mounting a directory,
or user home directories under a common directory).

; multiple users of the
same mount are fine, the potential conflcit is that if multiple systems mount
the same directory and modify the same files under it, the cache won't be
notified of updates on the server. The client pulls data from the server,
the server cannot asynchronously push unrequested updates to the client).

The "-o cache=fscache" mode uses Linux's fscache subsystem to provide
persistent local cacheing (which doesn't help concurrency at all). See
Documentation/filesystems/cacheing/fscache.txt for details.

This code makes no attempt to handle the full range of cacheing corner cases
other protocols wrestle with; v9fs just doesn't go there. The old saying is
"reliability, performance, concurrency: pick two" for a reason. Uncached mode
provides reliability and concurrency, cached mode provides performance and
one other (your choice which).

Even with cacheing, multiple users of the same mount on a client are fine,
the potential conflicit is that if multiple client systems the same directory
from a server and modify the same files under it, the client's cache won't be
notified of updates from other clients before naturally expiring. The client
pulls data from the server, the server cannot asynchronously push unrequested
updates to the client. In 9p the server only responds to client requests, it
never initiates transactions.