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
