こういう話はずいぶん前から知っていました。
ローカルのストレージ領域を CIFS で共有する場合と比較して、いろいろな問題が生じます。
現在、我が家では NAS4Free で ストレージを集約しているわけですが、過去の経緯でネットワークパスを変更したくない理由があって、 Linux(CentOS) で立てたファイルサーバー （ Samba サーバー）に NFS でストレージ領域をマウントして共有しています。
現在の環境に至るまで、自宅の環境を整備するたび調べて、試行錯誤を繰り返して対処してきたのですが、 自宅という超少人数（ほぼ自分一人）で使う分には、 不満のないレベルで安定したので、備忘録の意味もかねてまとめておきます。
まずは NFS クライアント側のマウント設定。
これを行わないとまずスループットが上がりません。 また Windows クライアントからのファイル書き込み時にエラーが発生する場合があります。
Samba で共有する領域なので、 /etc/fstab に記述すると言う前提で以下のようになります。
192.168.0.1:/mnt/mnt_zfs/Lib /mnt/mnt_nfs nfs rw,noatime,tcp,intr,nolock,rsize=4096,wsize=4096 0 0NFS サーバー (192.168.0.1) の /mnt/mnt_zfs/Lib を自身の /mnt/mnt_nfs へマウントする際、 読み書き可 (rw) 、 inode のアクセス時間を更新しない (noatime) 、 TCP 使用 (tcp) 、障害時などに NFS 要求の割り込みを許可 (intr) 、 ファイルロック機能無効 (nolock) 、読み込み (rsize) ・書き込み (wsize) 時のバッファサイズを 4096 に指定します。
バッファサイズですがいろいろ試しましたが、 8192, 4096, 2048 で最もスループットがでたのが今の環境 （ Samba サーバー： CentOS 7 /Samba 4.1.1 、 NFS サーバー： NAS4Free 9.2.0.1.943 ）では 4096 でした。
nolock のオプションは本来多人数で単一ファイルへ同時アクセスされることが想定される場合、 使ってはいけないオプション（らしい）ですが、これを設定しないと、 Windows クライアントからのファイル書き込み時にエラーが発生してしまいます。
一方で、 Samba 側の設定 /etc/samba/smb.conf で global セクションに以下のように kernel oplocks を無効にしさえすればよいとも 書かれていたところもあるのですが、うちの環境ではこの設定だけでは解消しませんでした。
[global]
: （略）
kernel oplocks = no
: （略）
我が家では NFS マウントの際の nolock オプションと、
上記の /etc/samba/smb.conf の kernel oplocks の設定は両方して施しています。以上、これで我が家のファイルサーバーはそこそこパフォーマンスがでています。
「これが決定版！おすすめ！！」って設定ではないですが、 NFS マウントの領域を Samba (CIFS) で公開する場合はお試し下さい。
それでもっといい設定があれば、教えて下さい m(_ _;)m
