From: NeilBrown <neilb@suse.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Steve Dickson <SteveD@redhat.com>, linux-nfs@vger.kernel.org
Subject: Re: [PATCH 4/4] mountd: delay reading etab until first request arrives.
Date: Fri, 23 Dec 2016 10:16:57 +1100 [thread overview]
Message-ID: <87mvfnpn9y.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <20161222203501.GA31461@fieldses.org>
[-- Attachment #1: Type: text/plain, Size: 2099 bytes --]
On Fri, Dec 23 2016, J. Bruce Fields wrote:
> On Wed, Dec 21, 2016 at 11:19:14AM +1100, NeilBrown wrote:
>> Reading etab may require hostname lookup, so it is not reliable
>> until the network is active.
>> But we want mountd to start before that so that it is ready
>> when the very first NFS request arrives.
>> So delay reading etab until that request arrives, by which time
>> the network must be online so hopefully hostname look will be reliable.
>>
>> An alternate would be to delay starting mountd and nfsd until the
>> network is on-line, but that will often be an unnecessary delay.
>
> One argument for that delay would be to get the grace period right: it's
> not really correct to start timing the grace period before you start
> accepting requests.
>
> In practice, with grace periods by default a minute and (I'm guessing)
> the delay here not even a few seconds, maybe it's a minor point.
>
> And in theory I guess knfsd could account for that by waiting to start
> the grace period timer until it receives its first rpc.
Interesting idea. One would need to be careful about the case where
there are no clients wanting to recover state, so some timeout without
seeing any RPC would be needed.
It's times like this that I wish the grace period was a lot shorter, but
was auto-extended whenever a state-recovery request arrived (maybe with
some limit). But that isn't what the spec say :-(
Thanks,
NeilBrown
>
> Anyway, that's not an objection to applying this patch.
>
> --b.
>
>>
>> Signed-off-by: NeilBrown <neilb@suse.com>
>> ---
>> utils/mountd/mountd.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/utils/mountd/mountd.c b/utils/mountd/mountd.c
>> index 5d9466f5c651..61699e62a6f0 100644
>> --- a/utils/mountd/mountd.c
>> +++ b/utils/mountd/mountd.c
>> @@ -852,8 +852,6 @@ main(int argc, char **argv)
>> sa.sa_handler = sig_hup;
>> sigaction(SIGHUP, &sa, NULL);
>>
>> - auth_init();
>> -
>> if (!foreground) {
>> /* We first fork off a child. */
>> if ((c = fork()) > 0)
>>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2016-12-22 23:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-21 0:19 [PATCH 0/4] Assorted nfs-utils patches NeilBrown
2016-12-21 0:19 ` [PATCH 1/4] nfsd: fix setting of minor version from config file NeilBrown
2016-12-21 0:19 ` [PATCH 3/4] nfs-server-generator: avoid using syslog NeilBrown
2016-12-21 0:19 ` [PATCH 4/4] mountd: delay reading etab until first request arrives NeilBrown
2016-12-22 20:35 ` J. Bruce Fields
2016-12-22 23:16 ` NeilBrown [this message]
2016-12-23 0:35 ` J. Bruce Fields
2016-12-21 0:19 ` [PATCH 2/4] nfsd: Do not permit manipulation of NFSv4.0, e.g. "-N 4.0" NeilBrown
2017-01-04 16:56 ` [PATCH 0/4] Assorted nfs-utils patches Steve Dickson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mvfnpn9y.fsf@notabene.neil.brown.name \
--to=neilb@suse.com \
--cc=SteveD@redhat.com \
--cc=bfields@fieldses.org \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).