All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anna Schumaker <schumaker.anna@gmail.com>
To: Trond Myklebust <trondmy@primarydata.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 1/9] NFSv4: Don't invalidate the directory twice
Date: Mon, 19 Dec 2016 12:07:35 -0500	[thread overview]
Message-ID: <bc1eca55-4193-0774-054a-9047a2fdb64e@gmail.com> (raw)
In-Reply-To: <DBC3F2C7-BF49-4209-B403-AAEB68D0A96A@primarydata.com>



On 12/19/2016 11:56 AM, Trond Myklebust wrote:
> What’s the filesystem you’re testing on?

I see this on xfs and ext4 but btrfs seems to work.  What do you mean by timestamp resolution?  I can't find the file in question in `ls`, but for another file `stat` tells me:

  File: file.10
  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
Device: fe31h/65073d    Inode: 1319795     Links: 1
Access: (0666/-rw-rw-rw-)  Uid: ( 1000/    anna)   Gid: (  100/   users)
Access: 2016-12-19 12:04:47.680033877 -0500
Modify: 2016-12-19 12:04:47.680033877 -0500
Change: 2016-12-19 12:04:47.680033877 -0500

I hope this helps!
Anna
> 
>> On Dec 19, 2016, at 11:54, Anna Schumaker <schumaker.anna@gmail.com> wrote:
>>
>> Hi Trond,
>>
>> On 12/17/2016 01:27 PM, Trond Myklebust wrote:
>>> If an operation that modified the directory raced with a GETATTR, then we
>>> don't need to invalidate the directory cache more than once.
>>
>> This patch causes cthon basic tests to fail with:
>>
>> ./test6: readdir
>>        ./test6: (/nfs/all) unlinked 'file.0' dir entry read pass 1
>>        ./test6: (/nfs/all) Test failed with 1 errors
>> basic tests failed
>>
>> Thanks,
>> Anna
>>>
>>> Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
>>> ---
>>> fs/nfs/nfs4proc.c | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
>>> index d33242c8d95d..713932440e07 100644
>>> --- a/fs/nfs/nfs4proc.c
>>> +++ b/fs/nfs/nfs4proc.c
>>> @@ -1088,12 +1088,15 @@ static void update_changeattr(struct inode *dir, struct nfs4_change_info *cinfo)
>>> 	struct nfs_inode *nfsi = NFS_I(dir);
>>>
>>> 	spin_lock(&dir->i_lock);
>>> +	if (dir->i_version == cinfo->after)
>>> +		goto out;
>>> 	nfsi->cache_validity |= NFS_INO_INVALID_ATTR|NFS_INO_INVALID_DATA;
>>> 	if (!cinfo->atomic || cinfo->before != dir->i_version)
>>> 		nfs_force_lookup_revalidate(dir);
>>> 	dir->i_version = cinfo->after;
>>> 	nfsi->attr_gencount = nfs_inc_attr_generation_counter();
>>> 	nfs_fscache_invalidate(dir);
>>> +out:
>>> 	spin_unlock(&dir->i_lock);
>>> }
>>>
>>>
>>
> 

  parent reply	other threads:[~2016-12-19 17:07 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-17 18:27 [PATCH 0/9] NFS client attribute cache performance improvements Trond Myklebust
2016-12-17 18:27 ` [PATCH 1/9] NFSv4: Don't invalidate the directory twice Trond Myklebust
2016-12-17 18:27   ` [PATCH 2/9] NFSv4: Update the attribute cache info in update_changeattr Trond Myklebust
2016-12-17 18:27     ` [PATCH 3/9] NFSv4: Don't discard the attributes returned by asynchronous DELEGRETURN Trond Myklebust
2016-12-17 18:27       ` [PATCH 4/9] NFS: Don't revalidate the file on close if we hold a delegation Trond Myklebust
2016-12-17 18:27         ` [PATCH 5/9] NFS: Clean up cache validity checking Trond Myklebust
2016-12-17 18:27           ` [PATCH 6/9] NFS: Only look at the change attribute cache state in nfs_weak_revalidate() Trond Myklebust
2016-12-17 18:27             ` [PATCH 7/9] NFS: Fix and clean up the access cache validity checking Trond Myklebust
2016-12-17 18:27               ` [PATCH 8/9] NFS: Remove unused function nfs_revalidate_inode_rcu() Trond Myklebust
2016-12-17 18:27                 ` [PATCH 9/9] NFS: Clean up nfs_attribute_timeout() Trond Myklebust
2016-12-19 16:54   ` [PATCH 1/9] NFSv4: Don't invalidate the directory twice Anna Schumaker
2016-12-19 16:56     ` Trond Myklebust
2016-12-19 17:00       ` Trond Myklebust
2016-12-19 17:07       ` Anna Schumaker [this message]
2016-12-19 17:30         ` Trond Myklebust
2016-12-19 19:05           ` Anna Schumaker

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=bc1eca55-4193-0774-054a-9047a2fdb64e@gmail.com \
    --to=schumaker.anna@gmail.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trondmy@primarydata.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.