RFC: patching fsshare in ZFS

Peter Eriksson pen at lysator.liu.se
Wed Jun 5 07:50:12 UTC 2019


Hi all!
 
I’ve been experimenting a little with adding support for a simple BerkelyDB-based “exports” database to mountd in order to speed things up for the ZFS share code. The changes to mountd are fairly simple, and the corresponding stuff was pretty simple to add to the ZFS code too last I tried it. Speeds things up quite a bit - no need to do linear searches through the /etc/zfs/exports file and no need to rewrite the file for changes either… With N*10000 NFS shared filesystems like we do this can be pretty nice to have. 

My current DB-based code supports multiple exports entries per filsystem by separating the “rows” in the database entry for a filesystem with NUL characters.

Let me know if there is some interest in this for others than just me.

- Peter



> 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