Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   "Benjamin Coddington" <bcodding@redhat.com>
To:     "Trond Myklebust" <trondmy@hammerspace.com>
Cc:     linux-nfs@vger.kernel.org
Subject: Re: [PATCH v1 04/10] NFS: Keep the readdir pagecache cursor updated
Date:   Thu, 21 Jan 2021 19:21:51 -0500
Message-ID: <7DD58BAC-33C5-4DBA-B692-3FB24186B7E4@redhat.com>
In-Reply-To: <187eb82fa8acad68141d026811945a56cc14b35d.camel@hammerspace.com>
References: <cover.1611160120.git.bcodding@redhat.com>
 <f803021382040dba38ce8414ed1db8e400c0cc49.1611160121.git.bcodding@redhat.com>
 <76fd114e0f4018cf7e00f565759e10acd1f0ba92.camel@hammerspace.com>
 <187eb82fa8acad68141d026811945a56cc14b35d.camel@hammerspace.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 21 Jan 2021, at 15:11, Trond Myklebust wrote:

> On Thu, 2021-01-21 at 20:00 +0000, Trond Myklebust wrote:
>> On Wed, 2021-01-20 at 11:59 -0500, Benjamin Coddington wrote:
>>> Whenever we successfully locate our dir_cookie within the
>>> pagecache,
>>> or
>>> finish emitting entries to userspace, update the pagecache cursor. 
>>> These
>>> updates provide marker points to validate pagecache pages in a
>>> future
>>> patch.
>>
>> How isn't this going to end up subject to the exact same problem that
>> Dave Wysochanski's patchset had?
>
> IOW: how is this not also making invalid assumptions around page cache
> layout stability across READDIR calls?

IIRC, Dave's approach was to store the index along with dir_cookie in
order to skip having to re-fill the cache to resume a listing.  That
approach assumed that the index still referred to page data aligned
with the current reader's dir_cookie.  But in between calls to
nfs_readdir() it would be possible for another reader to fill the cache 
with
a different alignment due to directory changes.  In which case the index 
is not
going to point to the next entry, we'll either skip entries or repeat 
them.

With this approach, we don't assume this is the case.  For every page 
with
data, the alignment of the entries is verified to be in the same 
position
as that reader's last pass through.  If not, the page data is discarded 
and
refreshed with a new READDIR op - just like an uncached_readdir path, 
but we
still fill the pagecache.  Every READDIR also updates the change_attr, 
so
even if there are cached pages beyond our current location that match 
our
alignment, we detect the case where those pages are actually invalid due 
to
changes on the server, and we re-fill them.

Another way to think about this is that instead of trying to cache the 
complete
representation of the directory aligned to the first entry in the 
pagecache,
we're instead just caching the results of any READDIR at convenient 
offsets
in the pagecache for other readers that might follow.  The READDIR 
results
are only usable if they match the current version of the directory and 
their
alignment is correct.

If you were to lseek to nearly the end of a directory, the first call to
nfs_readdir() will end up with results of a READDIR hitting the cache 
and
filling page->index 0.  That's ok because any other reader coming along 
with
a different alignment will discard that data and refresh it. We are 
going to
create a performance penalty for two readers that want to regularly fill
entries at different alignments, but I think that case is probably 
fairly
rare.  I am making a guess, but I think the most common usage of readdir 
is
by readers that want to traverse the entire directory in order.

So for that case all the readers benefit from the work of other 
processes,
the cache can be filled in parallel, and readers at the beginning don't
prevent readers at the end from filling in entries.  We no longer have 
to
worry whether we have enough memory to list a directory, or play games 
with
timeouts.

Ben