Linux NFSサーバーがユーザースペースアプリケーションではなくカーネルに実装されている理由を知りたいです。
私も知っていますユーザー空間NFSデーモン存在しますが、NFSサーバーサービスを提供する標準的な方法ではありません。
NFSサーバーをユーザースペースアプリケーションとして実行することは、カーネルの代わりにユーザースペースでデーモンを実行して追加のセキュリティを提供するので、これは好ましいアプローチだと思います。また、一般的なLinuxの原則に準拠しています。つまり、1つのことをうまくやってください（そしてデーモンはカーネルの仕事になるべきではありません）。
実際、カーネルで実行するときに私が考えることができる唯一の利点は、コンテキスト切り替えによるパフォーマンスの向上です（これが議論の余地がある理由です）。
それでは、これが実装されるべき文書化された理由はありますか？インターネットを検索しようとしましたが、何も見つかりませんでした。
多くの混乱があるようです。ファイルシステムのマウントについて尋ねるのではなく、提供について尋ねることです。ネットワークファイルシステムのサーバ側。非常に明確な違いがあります。ファイルシステムをローカルにマウントするには、カーネルがファイルシステムをサポートする必要があります（sambaやunfs3など）。
ベストアンサー1
unfs3私が知っている限り死んだ。ガネーシャまだ完全に成熟していませんが、現在最もアクティブなユーザースペースNFSサーバープロジェクトです。
Samba は異なるプロトコルを提供しますが、ユーザー空間で実行される成功したファイルサーバーの例です。
最近のパフォーマンス比較を見たことがありません。
その他の質問：
- 一般的なアプリケーションはパス名でファイルを検索しますが、
nfsdファイルハンドルとして見つけることができるはずです。これはトリッキーで、ファイルシステムのサポートが必要です（すべてのファイルシステムがそれをサポートできるわけではありません）。以前はユーザースペースでこれを行うことはできませんでしたが、最近カーネルにはシステムコールが追加されましたname_to_handle_at(2)。open_by_handle_at(2) - ファイルロック呼び出しをブロックするのが問題だったことを覚えているようです。現在のユーザースペースサーバーがこれをどのように処理するのかわかりません。 （ロックを待っているサーバースレッドを占有していますか、それともポーリングしていますか？）
- 最新のファイルシステムの意味（変更属性、委任、共有ロック）は、最初にカーネルで実装するのが簡単になる可能性があります（理論的にはほとんど実装されていません）。
- 権限、クォータなどを手動で確認するのではなく、uidを変更してこれを実行するために共通のカーネルvfsコードを使用しようとしています。 Linuxには、これを実行できるシステムコール（
setfsuid(2)）があります。忘れられた理由のために、サーバーでこれを使用することが予想よりも複雑になることがわかりました。
通常、カーネルサーバーの利点は、vfsとエクスポートされたファイルシステムとの緊密な統合です。より多くのカーネルインタフェース（ファイルハンドルシステムコールなど）を提供することでこれを補完できますが、それは簡単ではありません。一方、最近人々がエクスポートしようとしているいくつかのファイルシステム（Glusterなど）は、実際には主にユーザースペースに存在します。 FUSE を使用してカーネル nfsd からエクスポートできますが、新機能には FUSE インターフェイスへの拡張が必要になり、パフォーマンスの問題が発生する可能性があります。
ショートバージョン：良い質問です！