Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 4 Aug 2022 14:14:05 -0400
To:     Chuck Lever III <chuck.lever@oracle.com>
Cc:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: pynfs clean_init issue
Message-ID: <20220804181405.GC9019@fieldses.org>
References: <F80796C9-DFCE-4C7A-A2EE-4EB2075B9007@oracle.com>
 <20220804153816.GB9019@fieldses.org>
 <1C391A45-B2CC-4C90-86DD-1FB9C2000E7E@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1C391A45-B2CC-4C90-86DD-1FB9C2000E7E@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
From:   bfields@fieldses.org (J. Bruce Fields)
Precedence: bulk

On Thu, Aug 04, 2022 at 03:43:56PM +0000, Chuck Lever III wrote:
> It passes, but leaves the test file so that clean_dir does not work
> again until the old lease expires.

Oh, right.

> > But possibly cleanup should also be better.
> 
> This bug might prevent running these tests in an automation harness.
> I'd say cleanup does need to be better about this.
> 
> > I'm not sure what the right fix is.
> 
> Brute force: keep trying to delete that file if clean_dir receives
> NFS4ERR_DELAY?

Delegations block unlinks too so that probably doesn't help.

> init_connection somewhere needs to set up a callback service and
> leave it running.

The callback isn't too important, I think, if we want to return the
delegation at the end of the test we can do that without waiting for the
server to remind us.

Or maybe destroy the client at the end.  We have no DESTROY_CLIENTID
(this is 4.0), but we could do a client-rebooting SETCLIENTID/CONFIRM to
wipe out its state.

There may be limits to the kind of cleanup pynfs can do.  A test harness
should probably reboot the server between test runs.

--b.