linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Scott Mayhew <smayhew@redhat.com>
Cc: jlayton@kernel.org, linux-nfs@vger.kernel.org
Subject: Re: [pynfs PATCH 1/4] nfs4.1: add some reboot tests
Date: Fri, 15 Mar 2019 16:48:59 -0400	[thread overview]
Message-ID: <20190315204859.GB13567@fieldses.org> (raw)
In-Reply-To: <20190314211210.7454-2-smayhew@redhat.com>

On Thu, Mar 14, 2019 at 05:12:07PM -0400, Scott Mayhew wrote:
> +def testRebootWithManyManyManyClients(t, env):
> +    """Reboot with many many many clients
> +
> +    FLAGS: reboot
> +    CODE: REBT2c
> +    """
> +    return doTestRebootWithNClients(t, env, 1000)

My test server uses a 15 second lease time, mainly just to speed up
tests.  That's not enough for pynfs to send out reclaims for 1000
clients.

So I'm wondering whether that's a reasonable test or not.

On the one hand, we should be able to handle 1000 clients, and a 15
second lease is probably unrealistically short.  And maybe we could
choose more patient behavior for the server (currently it will wait at
most 2 grace periods while reclaims continue to arrive).

On the other hand, real clients will send their reclaims simultaneously
rather than one at a time.  And from a trace it looks like most of the
time's spent waiting for pynfs to send the next request rather than
waiting for replies.  So this is a bit unusual.

I'm inclined to drop the "many many many clients" tests.  It's easy
enough for someone doing reboot testing to patch the tests if they need
to.

By the way, the longest round trip time I see is the RECLAIM_COMPLETE.
I assume that's doing a commit to disk.  It looks like there's nothing
on the server to prevent processing RECLAIM_COMPLETEs in parallel so as
long as that's true I suppose we're OK.

--b.

  parent reply	other threads:[~2019-03-15 20:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-14 21:12 [pynfs PATCH 0/4] nfs4.1: add a bunch of reboot tests Scott Mayhew
2019-03-14 21:12 ` [pynfs PATCH 1/4] nfs4.1: add some " Scott Mayhew
2019-03-15 19:43   ` J. Bruce Fields
2019-03-15 19:52     ` Scott Mayhew
2019-03-15 20:50       ` J. Bruce Fields
2019-03-15 20:48   ` J. Bruce Fields [this message]
2019-03-18 14:30     ` Frank Filz
2019-03-18 14:57       ` 'J. Bruce Fields'
2019-03-14 21:12 ` [pynfs PATCH 2/4] nfs4.1: add some more " Scott Mayhew
2019-03-14 21:12 ` [pynfs PATCH 3/4] nfs4.1: still " Scott Mayhew
2019-03-14 21:12 ` [pynfs PATCH 4/4] nfs4.1: test delayed reclaim following a server reboot Scott Mayhew
2019-03-14 21:48 ` [pynfs PATCH 0/4] nfs4.1: add a bunch of reboot tests J. Bruce Fields
2019-03-14 23:18   ` Scott Mayhew
2019-03-15  1:00     ` J. Bruce Fields
2019-03-15  1:03       ` J. Bruce Fields

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=20190315204859.GB13567@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=jlayton@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=smayhew@redhat.com \
    /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).