RFC: patching fsshare in ZFS

[Rick Macklem]

Hi,

First off, sorry for sending this to all you guys. (I used to send this stuff to Josh P,
but I'm not sure which of you guys are best for FreeNAS/NFS related stuff.
If you let me know who you'd rather I email, then I'll only bother them;-)

I try to avoid ZFS like the plague, but there are a couple of things related the
nfsshare property that I think would be nice to patch.

1 - There is a simple patch by Quentin Rameau in PR#147881 that adds support
      for ";" to be used as a separator in the nfsshare property, so that multiple lines
      of exports can be generated. For example, for an nfsshare property of
      "-maproot=root host1; -ro host2", the following two exports lines would be
      generated (assuming /tank/vol1 is the file system mountpoint)
      /tank/vol1 -maproot=root host1
      /tank/vol1 -ro host2
     Right now, I think the nfsshare property only generates one line per file system,
     which has to apply to all clients, giving them all the same options.
     (I made a couple of comments related to this patch in the PR.)
     One question is whether an nfsshare property that is a null string or just
     whitespace is currently allowed? (I couldn't see anything in fsshare() that
     disallows it, but I don't know anything about the code used to set the property.)

2 - Peter has some NFS servers with 20000-72000+ file systems being exported.
      The current code in fsshare.c copies the exports file and then appends the new
       entry for a file system and then replaces the exports file with the new one.
       I think this file copying happens for every file system, which seems like a lot
       of overhead. (I forget what Peter said w.r.t. how long this takes, but I think it
       was quite a while.)
       My guess is that Pawel did this so that the update to the file would happen
       atomically.
       It seems to me that if mountd held a read lock on the export file while reading it
       and fsshare() held a write lock on the file while appending the new entry, that
       the file copying could be avoided?
       - The main problem I see w.r.t. doing this is that an old mountd binary that doesn't
         read lock the file could be broken by the fsshare() change.
         --> One way to avoid this would be to have the new mountd write more than
               just the pid in the MOUNTD_PID file so that fsshare() could tell if mountd was
               going to be read locking the file.
               OR
               Just don't MFC the change and assume that the new mountd would be
               released when the new fsshare() is (in FreeBSD13?).

Anyhow, I can tweak mountd.c and fsshare.c, but that's as far as I can take it.

Others would need to do testing and whatever it takes to get a change to fsshare.c
into the ZFS sources.

So, what do you think about this? rick