Date:   Fri, 15 Mar 2019 16:48:59 -0400
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
Message-ID: <20190315204859.GB13567@fieldses.org>
References: <20190314211210.7454-1-smayhew@redhat.com>
 <20190314211210.7454-2-smayhew@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190314211210.7454-2-smayhew@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

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.