Можно ли запускать доступный для записи общий ресурс 9pfs, когда cache=loose?

Существует еще один документ 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.