RFC: patching fsshare in ZFS
Rick Macklem
rmacklem at uoguelph.ca
Wed Jun 5 05:38:55 UTC 2019
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
More information about the freebsd-fs
mailing list