書き込み可能な9pルートファイルシステムで仮想マシンを実行しようとしています。デフォルトのキャッシュモードを使用すると、apt他のツールは9pfs自体の制限により失敗します。 aptで生成されるエラーメッセージは次のとおりです。
Apt: Unable to determine file size for fd ... : No such file or directory
オンラインでのクイック検索でlooseファイルシステムをマウントするときにキャッシュを設定する必要があることを提案しました。私のシステムにファイルシステムをマウントすると、cache=looseaptを正常に使用できます。
しかし、今ではファイルシステムの一貫性が心配です。カーネル文書これはcache=loose残念ながら、さらなる説明なしに読み取り専用システムにのみ適用されると述べられています。
したがって、次のように質問します。キャッシュが緩く設定された単一のマウントポイントを介してのみファイルシステムにアクセスし、ファイルシステムまたはそのデフォルトディレクトリにアクセスしない場合、一貫性/一貫性の問題は発生しますか？
つまり、単一のマウントポイントでのみ表示される場合、緩いキャッシュはファイルシステムの一貫性に影響しますか？
rw,trans=virtio,version=9p2000.L,cache=looseカーネルコマンドラインとfstabで次のマウントオプションを使用しています。
ベストアンサー1
またあります9p.txt文書は次の場所にあります。https://landley.net/kdocs/Documentation/filesystems/9p.txt特定のコンテンツの詳細なリストがあります。キャッシュモードそして他の項目。
単一のシステムにアクセスする場合、キャッシュはアクティビティを妨げてはいけません。ただ9pはできないというだけだよ宣伝するあるクライアントから同じ共有をマウントする別のクライアントへの変更。次回のリクエスト時にのみ新しいアップデートが表示されます。
最初の2つの段落を除いて、他の文書は主にリンクされた文書の代替文書です。マウントポイントを正しく設定するために実行したいことを理解するには、両方の文書を読む必要があります。次の内容だけが再現されます。キャッシュモードセクションを参照してください。
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.