On Wed, May 25, 2016 at 09:48:21PM +0100, Al Viro wrote:
> 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?
Nope, no reason at all. We'll fix it properly, hopefully by 4.8, but we
at least want the parallelism for now in the easy case when we don't
have delayed nodes.
> Conversely, are we really OK
> with changes to directory happening during that "unlock and relock exclusive"?
Yeah, so at that point, the only thing we've done is checked if we had
to emit the "." and ".." entries, which is safe because of f_pos_lock,
and allocated a struct btrfs_path. So we'd be alright if something came
in and changed the directory during that window.
--
Omar
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
