From: Al Viro <viro@ZenIV.linux.org.uk>
To: Chris Mason <clm@fb.com>,
dsterba@suse.cz, Omar Sandoval <osandov@osandov.com>,
linux-btrfs@vger.kernel.org, kernel-team@fb.com,
Omar Sandoval <osandov@fb.com>
Subject: Re: [PATCH] Btrfs: fix ->iterate_shared() by upgrading i_rwsem for delayed nodes
Date: Wed, 25 May 2016 21:48:21 +0100 [thread overview]
Message-ID: <20160525204821.GH14480@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20160525202226.djc7dk4uhzuleets@floor.thefacebook.com>
On Wed, May 25, 2016 at 04:22:26PM -0400, Chris Mason wrote:
> On Wed, May 25, 2016 at 10:11:29PM +0200, David Sterba wrote:
> > On Fri, May 20, 2016 at 01:50:33PM -0700, Omar Sandoval wrote:
> > > Commit fe742fd4f90f ("Revert "btrfs: switch to ->iterate_shared()"")
> > > backed out the conversion to ->iterate_shared() for Btrfs because the
> > > delayed inode handling in btrfs_real_readdir() is racy. However, we can
> > > still do readdir in parallel if there are no delayed nodes.
> >
> > So this is for current master (pre 4.7-rc1), I'll add an appropriate
> > merge point for to my for-next.
>
> I'll get this bashed on in a big stress.sh run, but it looks good to me.
I really don't like that approach, TBH ;-/ Is there any reason to exclude
lookups for the duration of that thing? Conversely, are we really OK
with changes to directory happening during that "unlock and relock exclusive"?
next prev parent reply other threads:[~2016-05-25 20:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-20 20:50 [PATCH] Btrfs: fix ->iterate_shared() by upgrading i_rwsem for delayed nodes Omar Sandoval
2016-05-25 20:11 ` David Sterba
2016-05-25 20:22 ` Chris Mason
2016-05-25 20:48 ` Al Viro [this message]
2016-05-25 22:11 ` Omar Sandoval
2016-06-17 17:55 ` Omar Sandoval
2016-06-17 17:59 ` Omar Sandoval
2016-06-20 15:07 ` David Sterba
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=20160525204821.GH14480@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=clm@fb.com \
--cc=dsterba@suse.cz \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=osandov@fb.com \
--cc=osandov@osandov.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).