Question on mountd

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Question on mountd

Olavi Kumpulainen
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.

/Olavi


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Question on mountd

Ian Lepore-3
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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Question on mountd

Ian Lepore-3
On Thu, 2017-08-10 at 19:31 +0200, Olavi Kumpulainen wrote:
> 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?
>

With -S, mountd sends a NFSSVC_SUSPENDNFSD command to nfsd, which I
presume makes nfsd finish any client requests in progress and stop
handling new client requests, then mountd manipulates the in-kernel
data, then it sends NFSSVC_RESUMENFSD.  I think the net effect is that
no client requests which rely on the in-kernel mount-export data can be
processed while mountd is manipulating the data.  You would think this
would be the default behavior, but maybe the delays are so bad for some
use cases that it was made optional with -S.

I should note I'm not an expert on this stuff, I'm making a lot of
assumptions from a little bit of looking at code.

-- Ian

> /Olavi
>
>
> >
> > On 10 Aug 2017, at 17:51 , Ian Lepore <[hidden email]> 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
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"