ZFS and NFS to multiple NIC/netwokrs

M

magmos_019

Hi!

Version of FreeBSD is 9.1 RC-2.

I have set up a fileserver which is connected to a Poervault MD1200 box. The file server has two nics. Each one connected via crossed patch cable to one application server each. In order to maximize performance I wanted to do direct connection from the application server via crossed patch cables instead of doing a small local network with a switch using only one of the nics on the file server.

Everything is working fine if I type the command
# zfs sharenfs "-network 192.168.1.0/24" pool/shared
I can then connect (NFS) from the application server relying on nic number 1.
If I type
# zfs sharenfs "-network 192.168.2.0/24" pool/shared
I have no problem connecting from the application server relying on nic number 2.

Any suggestions on how to "zfs sharenfs" to get it up working simultaneously for both application servers?

For example a command like
# zfs sharenfs "-network 192.168.1.0/24 -network 192.168.2.0/24" pool/shared
But this does not work.

Best regards Magnus
 
  • Thanks
Reactions: Oko
I've had some problems getting it to accept multiple network statements too.

This may work though: # zfs sharenfs "network 192.168.1.0/24,network 192.168.2.0/24" pool/shared
 
This pops up on the mailing lists every now and then. The ZFS property for NFS is very nice, especially because it can be inherited by sub datasets and automatically tells the NFS server to reload the config but it really doesn't really handle complex setups very well.

I'm not sure whether Solaris has much simpler ways of handling this or whether they have the same problem but shoving loads of information into a ZFS property just gets messy.

Personally I would just leave the sharenfs option to off and add the entries manually to /etc/exports. There is nothing special about the ZFS property - it just updates /etc/zfs/exports. If you do a 'ps ax' you'll notice mountd is told to read both files.
 
Yes, the sharenfs property is a bit of a hack on FreeBSD. On Solaris it's able to directly communicate with NFS.

If all else fails you can always resort to the old way of adding filesystems to /etc/exports.
 
This is a limitation of the exports(5) format, that does not allow to specify all settings for one file system in one line. There is PR kern/147881 about ZFS and NFS exprots, I suggest to read discussion in this PR.
 
Multiple networks on the same line was never an issue with exports(5).

Code: 
/usr/ports    -network 2001:980:xxx:xxx::/64 -network 192.168.1.0/24
 
The limitations mentioned in the kern PR relate to not being able to specify different options (mapall/maproot/ro/rw/etc) for different hosts on the same line, not just multiple networks.

However, on a FreeBSD 9.0 machine I was unable to get any entry with multiple network statements to be picked up: I tried '-network=xxxx/x' and '-network xxxx/x'

Code: 
/storage/backups   -network 192.168.0.0/24 -network 10.0.0.0/24

Code: 
Nov  6 11:02:12 backup mountd[58538]: bad exports list line /storage/backups       -network 192.168.0.0/24 -network

Separating them with a comma in the ZFS property appears to just be converted to a space in the exports file so it produces exactly the same output as just using a space as above.

By the look of it this hasn't changed in 9.1 seeing as that's what the OP is using so I would suggest /etc/exports is the only option for now.
 
Yes, that PR is about different options for different address specifications. I gave this PR just to show possible solutions, and those solutions have relation to this thread's topic since the semantics of the zfs command used for sharing ZFS file system requires to give all settings for one file system in one line.

It is impossible to give all settings for one file system in one line because: 1) the -network option cannot be used with other address specifications in one line (networks and hosts), 2) export options cannot be inherited and redefined per address specification in one line, 3) there is no way to give default address specification with other address specifications in one line.

If somebody think that it is possible to specify the -network option with other address specifications, then please check this on a real system. By the way exports(5) says that the -network option must be a single address specification option in one line.c That's why this is a limitation of the current exports(5) rules.
 
Hmmm.. I could swear I had used this before but you're right, it doesn't work.
This does work though:
Code: 
/usr/ports    -network 2001:980:xxx:xxx::/64
/usr/ports    -network 192.168.1.0/24
 
The mountd was modified many times and as a result something that worked before, cannot work now. My opinion is that several -network options in one line should be supported in the same way as it is done for several host names in one line. But exports(5) considers these two cases differently. Personally I do not remember whether several -network options in one line worked before, I just followed exports(5) rules and EXAMPLES.

Another example is the -alldirs option, that does not work now. As a result configurations that worked several years ago and are written in respect to the exports(5) rules do not work on recent FreeBSD versions. For detail information and updates to mountd search "mountd" in FreeBSD PR database.
 
Ok, thank you all for input!

I stopped using NFS with ZFS so I did
# zfs set sharenfs=off pool/shared
Then I added this to /etc/exports:
Code: 
/pool/shared 192.168.1.2
/pool/shared 192.168.2.2

In order to restart mountd after editing /etc/exports I used the command:
# killall -HUP mountd
then I do not have to restart the server.

Now everything works fine.

Tahnks and best regards MAgnus
 
A tip about debugging 'zfs sharenfs': You can see the exports line that is generated by the command in /etc/zfs/exports.

I've found that anything other than a trivial export is a bit a pain with 'zfs sharenfs'.

PS: How on earth do you format commands inline in posts?
From Phoenix: Using the [ cmd ] tag. :) Also shown as the # button in the editor.
 
  • Thanks
Reactions: Oko
You must log in or register to reply here.
Back
Top