NFSv3のように動作するRHEL6NFSv4クライアント？
私の理解では、NFSv4クライアントはサーバー上のNFSv4サービスにすぐに接続し、rpcbindポートマッパーとマウントされたサービスの相互作用を完全にスキップする必要がありますが、RHEL6クライアントは常に最初にrpcbindサービスに接続してマウントされたポートを取得し、マウントされたフォームをエクスポートし、最後にNFSv4サービスに接続します。 tcpdumpを使用して監視されます。
すべての指示（マウントコマンドの出力とTCPの検査）により、マウント操作が完了すると、クライアントとサーバーはNFSv4を使用します。
これは、クライアントにNFSv4のみを強制しようとするために遭遇したすべてのことを実行した場合でも発生します。例：
- /etc/nfsmount.confでNfsvers = 4を設定する
- Vers = 4オプションで明示的にマウント
- NFSポートを明示的に設定します。 （mountコマンドおよびnfsmount.conf内）
私は完全にベースから外れていますか、それとも何かが正しくありませんか？これは私にとって問題です。NFSクライアントは、NFSv4エクスポートをマウントする前にUDP経由でサーバー上のrpcbindに到達できることを要求し、不思議なUDPパケット損失が発生します（はい、私はネットワーク担当者と協力していますこのフロント）は、マウントが完全に失敗するか、完了するまでに長い時間がかかる原因になっています。
Libtirpcソースを調べて、常にUDPを使用してRPCポートマッパーに接続していることを確認しましたが、ポートマッパーとマウントされたサービスを完全に排除したいと思います。
「rpcinfo-d」を使用してNFSサーバーでUDPポートマッパーサービスの登録を解除しようとしましたが、そのサーバーをターゲットとするすべてのNFSマウントが失敗します（クライアントは、RPCbindがUDPポート111でリッスンしているサーバーを要求します）。また、運が悪かったので/ etc/netconfigをいじってみました。
誰かがこの動作に出くわしたり、NFSv4について十分に知っているので、私には非現実的な期待があると教えてくれますか？
私はこれをautofsまでさかのぼりました。 /etc/auto.netを使用して、showmountコマンドを使用してエクスポートのリストを取得するように設定されています。 showmountコマンドは、NFSマウントが発生する前に、rpcbindおよびmountdへのアクセスを担当していたため、マウントオプションを変更しようとしても効果がありませんでした。
/etc/auto.netを改訂し、問題を修正しました。
補足：さまざまな場所で見たように、auto.masterの「-hosts」オプションを使用すると、rpcbindおよびmountdアクセスも発生しました。すべてのホストがNFSv4であると仮定すると、auto.netにすべてのNFSv4サーバーのルートをマウントさせるだけで問題ないことがわかりました。