我正在尝试在可写 9p 根文件系统上运行虚拟机。当使用默认的缓存模式，apt并且其他一些工具失败时；可能是由于 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 中。
答案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.