캐시=느슨한 경우 쓰기 가능한 9pfs 공유를 실행할 수 있습니까?

Question

또 있다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.

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.

캐시=느슨한 경우 쓰기 가능한 9pfs 공유를 실행할 수 있습니까?

답변1

관련 정보