長いLinuxユーザーとして、私はFreeBSDを新しいNASサーバーとして使用してきました。
交換するLinuxサーバーには、一対のNFSマウントがあります。最初のものは読み書き可能で、2番目は読み取り専用です。共有フォルダの物理的な場所は同じRAIDファイルシステムにあります。
このアプローチのアイデアは、rw共有を介して新しいファイルを準備し、管理者が削除の危険なしに将来のアクセス用に準備されたファイルをro共有に移動することです。
Linux(/ dev / md0は/ data / sharesにマウントされています)では、/ etc / exportsファイルは次のようになります。
/data/shares/rw 192.168.1.0/24(rw)
/data/shares/ro 192.168.1.0/24(ro)
FreeBSDを設定すると、/ dataにルートZFS raidz2プールが作成されました。
zpool create data raidz2 /dev/ada0 /dev/ada1 /dev/ada2 /dev/ada3 /dev/ada4
次に、/ data / sharesの共有データセット:
zfs create data/shares
その後、FreeBSD構文を使用して共有用の類似した/ etc / exportsファイルを作成しました。
/data/shares/rw -network=192.168.1.0/24
/data/shares/ro -ro -network=192.168.1.0/24
ただし、これにより単一のrw共有のみが発生し、/var/log/messagesにエラーメッセージが表示されます。
mountd[63092]: can't change attributes for /data/shares/ro: netcred already exists for given addr/mask
mountd[63092]: bad exports list line '/data/shares/ro -ro -network'
さらなる研究によると、FreeBSD NFS文書には以下が含まれていることがわかりました。
クライアントはファイルシステムごとに一度だけ指定できます。たとえば、/ usrが単一のファイルシステムの場合、両方のエントリは同じホストを指定するため、次のエントリは何の影響もありません。
# Invalid when /usr is one file system /usr/src client /usr/ports client
この場合、正しい形式はアイテムを使用することです。
/usr/src /usr/ports client
ただし、両方の項目が同じ構成を持つため、この構文は機能しません。つまり、どちらも読み取り/書き込み、または両方読み取り専用です。
この観点から見ると:
- Linux NFS は、各クライアントホストの共有レベルで構成されます。
- FreeBSD NFSは、各クライアントホストのファイルシステム全体に設定されます。
これが行き止まりの路地につながるようです。このユースケースを実装する唯一の方法は、別のZFSデータセットを使用することです(私はこれを避けたい)。
要約すると、いくつかの質問があります。
- FreeBSDはなぜ同じネストされたネットワークで複数の共有を許可しないのですか?
- 有効なユースケースが実装されるのを妨げるので、将来変更される可能性はありますか?
- 複数のZFSデータセットを使用する以外に、他のソリューションはありますか?
おそらくこの質問は満足のいく解決策につながらないかもしれませんが、少なくともLinuxからFreeBSDに移行するときに同じ問題に直面する可能性がある他の人にとっては便利です。
答え1
はい、そうであれば、mountd
NFSクライアントはディレクターを要求できますが(許可されている場合)、ファイルシステムは管理されているため、mountd
コードはファイルシステムのみを追跡します。