patch to improve perf for handling exports of large numbers of file systems

Rick Macklem rmacklem at uoguelph.ca
Tue May 7 00:50:18 UTC 2019


Hi,

Peter has reported to me via email that updating exports when mountd receives
a SIGHUP takes about 16seconds.  This isn't surprising, since he has 20,000+
file systems to export.
The current code deletes all 20,000+ exports in the kernel and then re-exports
everything in the exports file while having the nfsd suspended (assuming the "-S"
option is being used). It was designed decades ago when a system only had a
few file systems, but sometimes many exported directories within a file system.

The attached patch is a first draft (minimally tested) for the addition of a "-I" option
for mountd. When mountd is started with this "-I" option, it processes the exports
file(s) into the structures that mountd uses and then compares the old and new
structures, only doing unexport/re-export for the ones that have changed,
when it receives a SIGHUP.

At the moment, the algorithm for doing the comparison isn't efficient, but at least
it isn't doing a lot of system calls to unexport/re-export. (A simple change from using a single linked list to a hash table of linked lists for the "struct exportlist" would help the
comparison algorithm a lot, but I wanted to hold off on that until what I have
has seen more testing, since it will make the patch even more complex.)

I hope that Peter can test this (and anyone else willing to do so, please do
since there are many variants within the exports file(s) and I might not think
of them all to test).
The patch is "noisy", since it puts a bunch of debug stuff out via syslog().
You can get rid of this by simply deleting the syslog(..); lines that are not indented.

Anyone who can test this, it would be appreciated, rick
ps: Without "-I", the behaviour should not have changed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mountd-exp.patch
Type: application/octet-stream
Size: 23798 bytes
Desc: mountd-exp.patch
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20190507/e90d36d4/attachment.obj>


More information about the freebsd-fs mailing list