Date: Fri, 19 Jan 2018 23:24:44 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Emmanuel Vadot <manu@bidouilliste.com> Cc: Emmanuel Vadot <manu@FreeBSD.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r328129 - head/sys/fs/nfsserver Message-ID: <YTOPR0101MB2172962A27DA38FFFEC3479ADDEF0@YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <20180119115408.f333d3a6ec8d762e73f1d844@bidouilliste.com> References: <201801181528.w0IFSnWm053535@repo.freebsd.org> <20180118163855.b0a55427709c52d0ec2482c9@bidouilliste.com> <YTXPR0101MB21741F3254BD5F9381B42DBADDE80@YTXPR0101MB2174.CANPRD01.PROD.OUTLOOK.COM>, <20180119115408.f333d3a6ec8d762e73f1d844@bidouilliste.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Emmanuel Vadot wrote:
[stuff snipped]
> So should we warn once or maybe return EBUSY on unloading if there is
>still lock structures ?
My intent was that a module unload would clear out all data structures,
so I would so no. I would also say that I envisioned an unload of nfsd.ko a=
s
a last resort, to free up the data structures.
It should refuse to unload if the nfsd daemon is running.
Isolan used to unload/load the nfsd.ko a lot, because they preferred that
for testing and software updates.
I, personally, have never done so (except once in a while to see if it work=
s),
so I'll admit I have trouble understanding why you would do so?
Rebooting an NFSv4 server when clients are mounted forces the clients
to do state recovery during a grace period (2 minutes+) right after boot.
This isn't something that I would recommend as a routine exercise, but
at least it should recover the opens/locks if it goes smoothly.
(I can't recall for sure, but I don't think an unload/reload of the nfsd.ko
followed by a startup of the nfsd daemon does this? If I am wrong and
it does do this, then this is exactly like a reboot w.r.t. nfs service.
If you look at a packet trace in wireshark just after the server restart,
you would see errors like NFS4ERR_STALE_CLIENTID, NFS4ERR_STALE_STATEID,
NFS4ERR_BAD_SESSION that indicates to the client that recovery of state is
needed.
--> If this state recovery isn't happening then your mounts will probably b=
e
broken, at least w.r.t. byte range locking.
If the unload/reload doesn't do this, then a reboot is preferable.
Because of this rather complex state recovery exercise, any reboot or
unload/reload/restart of the nfsd should be done only when absolutely
necessary, imho.
If you can't run a server for an extended period with an unload of the
nfsd.ko or a reboot, using NFSv3 mounts would be a safer bet.
I wrote:
> For this case, normally all lock structures should go away when clients
> unmount and unloading the nfsd module while there are active mounts
> is not a safe practice. (Again NFSv4 isn't like NFSv3, there is server st=
ate
> for NFSv4.)
>
> rick
rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTOPR0101MB2172962A27DA38FFFEC3479ADDEF0>