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"?
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
