From: "Benjamin Coddington" <bcodding@redhat.com>
To: "Anna Schumaker" <schumaker.anna@gmail.com>
Cc: "Linux NFS Mailing List" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH v1 07/10] NFS: Support headless readdir pagecache pages
Date: Thu, 21 Jan 2021 12:57:12 -0500 [thread overview]
Message-ID: <4DE5379B-E52D-4C94-8701-29FEFCE8C438@redhat.com> (raw)
In-Reply-To: <CAFX2Jf=Kg+fbxSfgJ_Kzxe6LerQ8RcZu_8AYp2JFF4THDfy8fQ@mail.gmail.com>
On 21 Jan 2021, at 12:24, Anna Schumaker wrote:
> Hi Ben,
>
> On Wed, Jan 20, 2021 at 12:04 PM Benjamin Coddington
> <bcodding@redhat.com> wrote:
>>
>> It is now possible that a reader will resume a directory listing
>> after an
>> invalidation and fill the rest of the pages with the offset left over
>> from
>> the last partially-filled page. These pages will then be recycled
>> and
>> refilled by the next reader since their alignment is incorrect.
>>
>> Add an index to the nfs_cache_array that will indicate where the next
>> entry
>> should be filled. This allows partially-filled pages to have the
>> best
>> alignment possible. They are more likely to be useful to readers
>> that
>> follow.
>>
>> This optimization targets the case when there are multiple processes
>> listing the directory simultaneously. Often the processes will
>> collect and
>> block on the same page waiting for a READDIR call to fill the
>> pagecache.
>> If the pagecache is invalidated, a partially-filled page will usually
>> result. This partially-filled page can immediately be used by all
>> processes to emit entries rather than having to discard and refill it
>> for
>> every process.
>>
>> The addition of another integer to struct nfs_cache_array increases
>> its
>> size to 24 bytes. We do not lose the original capacity of 127 entries
>> per
>> page.
>
> This patch causes cthon basic test #6 to start failing with unexpected
> dir entries across all NFS versions:
>
> ./test6: readdir
> basic tests failed
> ./test6: (/mnt/test/anna/Connectathon/cthon04) unexpected dir
> entry 'h'
Ah, yes -- because we /must/ revalidate before using any cached pages.
I
think this test unlinks files and that would be a breakage.
> Luckily, the next patch seems to resolve this issue. Could they maybe
> be squashed together?
Yes, they should be squashed - I'll do that in another pass. I'd like
to
get rid of uncached_readdir() altogether and then send another version.
Thanks for the test!
Ben
next prev parent reply other threads:[~2021-01-21 18:00 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-20 16:59 [PATCH v1 00/10] NFS client readdir per-page validation Benjamin Coddington
2021-01-20 16:59 ` [PATCH v1 01/10] NFS: save the directory's change attribute on pagecache pages Benjamin Coddington
2021-01-20 16:59 ` [PATCH v1 02/10] NFSv4: Send GETATTR with READDIR Benjamin Coddington
2021-01-20 16:59 ` [PATCH v1 03/10] NFS: Add a struct to track readdir pagecache location Benjamin Coddington
2021-01-20 16:59 ` [PATCH v1 04/10] NFS: Keep the readdir pagecache cursor updated Benjamin Coddington
2021-01-21 20:00 ` Trond Myklebust
2021-01-21 20:11 ` Trond Myklebust
2021-01-22 0:21 ` Benjamin Coddington
2021-01-20 16:59 ` [PATCH v1 05/10] NFS: readdir per-page cache validation Benjamin Coddington
2021-01-20 20:08 ` kernel test robot
2021-01-20 16:59 ` [PATCH v1 06/10] NFS: stash the readdir pagecache cursor on the open directory context Benjamin Coddington
2021-01-20 16:59 ` [PATCH v1 07/10] NFS: Support headless readdir pagecache pages Benjamin Coddington
2021-01-21 17:24 ` Anna Schumaker
2021-01-21 17:57 ` Benjamin Coddington [this message]
2021-01-20 16:59 ` [PATCH v1 08/10] NFS: Reset pagecache cursor on llseek Benjamin Coddington
2021-01-20 16:59 ` [PATCH v1 09/10] NFS: Remove nfs_readdir_dont_search_cache() Benjamin Coddington
2021-01-20 16:59 ` [PATCH v1 10/10] NFS: Revalidate the directory pagecache on every nfs_readdir() Benjamin Coddington
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=4DE5379B-E52D-4C94-8701-29FEFCE8C438@redhat.com \
--to=bcodding@redhat.com \
--cc=linux-nfs@vger.kernel.org \
--cc=schumaker.anna@gmail.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).