Question on mountd

[Olavi Kumpulainen]

Thanks Ian,

Just a small follow up question - The reason to why -S works is that mountd cannot interrupt the execution thread of a NFS request from a client?
Is this true in a multicore system as well?

/Olavi


> On 10 Aug 2017, at 17:51 , Ian Lepore <ian at FreeBSD.org> wrote:
> 
> On Thu, 2017-08-10 at 16:56 +0200, Olavi Kumpulainen wrote:
>> Hi guys,
>> 
>> I notice that mount SIGHUP’s mountd every time mount succeeds. The
>> SIGHUP causes mountd to remount all exported directories.If this
>> happens while a NFS-client is accessing a share, an access error may
>> occur.
>> For this purpose, there is an option to mount, -S, which locks nfsd
>> while the remount is executing.
>> 
>> Can anyone of you share why mount needs to SIGHUP mountd in the first
>> place? It would make sense if mountd is restarted whenever
>> /etc/exports is modified, but always seems like overkill.
>> 
> 
> Based on looking through the mountd code a bit... When a new filesystem
> is mounted, it may be mounted on one of the mount points listed in
> /etc/exports.  If there was no fs mounted there previously, then mountd
> might have failed to set the in-kernel export attributes the last time
> it processed the exports file, so it has to do the processing again
> after the mount to update the in-kernel export data.  It would be
> really complex for mountd to try to figure out the minimal set of "what
> changed" after a mount succeeds, so it just completely reprocesses the
> exports file, first removing all export data from the kernel, then re-
> applying it all.
> 
> So, all in all, I think the right fix for this is to add
> "mountd_flags="-r -S" to your rc.conf file (-r is a default from
> /etc/defaults/rc.conf).
> 
> -- Ian