review of nfsd rc.d script patch

[Rick Macklem]

Hi,

For the pNFS service MDS machine, the nfsd can't be started until all nfs mounts
in /etc/fstab are done.
I think that adding "mountcritremote" to the "# REQUIRE:" line is sufficient to do this?

I don't think delaying the startup of the nfsd daemon until after any NFS mounts
are done will do any harm, but if others think it would be a POLA violation,
I could make this dependent on the pNFS service being enabled.
Does anyone think this would cause a POLA violation?

If someone familiar with the rc scripts could review this little patch, it would be
appreciated:
--- nfsd.old 2018-06-15 16:07:54.279786000 -0400
+++ nfsd 2018-06-15 16:08:43.934603000 -0400
@@ -4,7 +4,7 @@
#

# PROVIDE: nfsd
-# REQUIRE: mountd hostname gssd nfsuserd
+# REQUIRE: mountcritremote mountd hostname gssd nfsuserd
# KEYWORD: nojail shutdown

. /etc/rc.subr

Thanks, rick
_______________________________________________
freebsd...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"

[Don Lewis]

On 15 Jun, Rick Macklem wrote:
> Hi,
>
> For the pNFS service MDS machine, the nfsd can't be started until all nfs mounts
> in /etc/fstab are done.
> I think that adding "mountcritremote" to the "# REQUIRE:" line is sufficient to do this?
>
> I don't think delaying the startup of the nfsd daemon until after any NFS mounts
> are done will do any harm, but if others think it would be a POLA violation,
> I could make this dependent on the pNFS service being enabled.
> Does anyone think this would cause a POLA violation?

Sounds like that would break cross mounts. Back in the olden days
before the automounter, I would set up workstation clusters with hosta
exporting local filesystem /home/hosta, and hostb exporting /home/hostb.
In addition, hosta would do a bg NFS mount of /home/hostb and hostb
would do a bg NFS mount of /home/hosta. That way everybody would have a
consistent view of everything. If a power failure took down everything,
the first system up would export its local filesystem and even though it
wouldn't be able to mount any remote filesystems, mount would background
itself at the boot would complete. As the remaining machines came up,
they would be able to mount the remote filesystems of the machine that
came up earlier, and the early machines would mount the filesystems from
the later machines as they became available.

If nfsd is delayed until all the NFS filesystems are mounted, the above
setup would deadlock.

[Rick Macklem]

Don Lewis wrote:
>On 15 Jun, Rick Macklem wrote:
>> Hi,
>>
>> For the pNFS service MDS machine, the nfsd can't be started until all nfs mounts
>> in /etc/fstab are done.
>> I think that adding "mountcritremote" to the "# REQUIRE:" line is sufficient to do this?
>>
>> I don't think delaying the startup of the nfsd daemon until after any NFS mounts
>> are done will do any harm, but if others think it would be a POLA violation,
>> I could make this dependent on the pNFS service being enabled.
>> Does anyone think this would cause a POLA violation?
>
>Sounds like that would break cross mounts. Back in the olden days
>before the automounter, I would set up workstation clusters with hosta
>exporting local filesystem /home/hosta, and hostb exporting /home/hostb.
>In addition, hosta would do a bg NFS mount of /home/hostb and hostb
>would do a bg NFS mount of /home/hosta. That way everybody would have a
>consistent view of everything. If a power failure took down everything,
>the first system up would export its local filesystem and even though it
>wouldn't be able to mount any remote filesystems, mount would background
>itself at the boot would complete. As the remaining machines came up,
>they would be able to mount the remote filesystems of the machine that
>came up earlier, and the early machines would mount the filesystems from
>the later machines as they became available.
>
>If nfsd is delayed until all the NFS filesystems are mounted, the above
>setup would deadlock.

I think you would have used the "bg" mount option on the NFS mounts to get
the above to work? (That is what makes the mount go "background" if it can't
contact the NFS server.)

If so, this would still behave the same after this patch.

The patch forces "mountcritremote" to complete before nfsd is run (to be honest,
since "m" comes before "n", I think that happens anyhow? This patch just tries to
ensure that).
It does not force waiting for mount completion if "bg" is specified.
(Put another way, "bg" can't be used for mounts of DSs for the pNFS server setup.)

rick
ps: I recall a small company that only had a few SGI workstations and did a setup
like the above. However, they weren't very good at configuring it and, as such,
everyone would run around for a half hour after a power failure, trying to get
the workstations back up;-)