Date: Wed, 5 Jun 2019 05:38:51 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Alexander Motin <mav@FreeBSD.org>, "mmacy@ixsystems.com" <mmacy@ixsystems.com>, "ryan@ixsystems.com" <ryan@ixsystems.com>, "pjd@freebsd.org" <pjd@freebsd.org>, Peter Eriksson <pen@lysator.liu.se> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@FreeBSD.org> Subject: RFC: patching fsshare in ZFS Message-ID: <YQXPR01MB3128B7972F1DCDF2A163859DDD160@YQXPR01MB3128.CANPRD01.PROD.OUTLOOK.COM>
next in thread | raw e-mail | index | archive | help
Hi,
First off, sorry for sending this to all you guys. (I used to send this stu=
ff 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 relate=
d 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 suppor=
t
for ";" to be used as a separator in the nfsshare property, so that m=
ultiple lines
of exports can be generated. For example, for an nfsshare property of
"-maproot=3Droot host1; -ro host2", the following two exports lines w=
ould be
generated (assuming /tank/vol1 is the file system mountpoint)
/tank/vol1 -maproot=3Droot host1
/tank/vol1 -ro host2
Right now, I think the nfsshare property only generates one line per f=
ile 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 exporte=
d.
The current code in fsshare.c copies the exports file and then append=
s 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, b=
ut 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 wh=
ile 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 bin=
ary 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 mo=
re 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 wou=
ld 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 fs=
share.c
into the ZFS sources.
So, what do you think about this? rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YQXPR01MB3128B7972F1DCDF2A163859DDD160>