Re: [PATCH v3 3/3] Btrfs: implement full reflink support for inline extents

Filipe Manana
2020-03-05T17:30:07Z

On Thu, Mar 5, 2020 at 4:39 PM David Sterba <dsterba@suse.cz> wrote:
>
> On Thu, Mar 05, 2020 at 03:03:14PM +0000, Filipe Manana wrote:
> > On Thu, Mar 5, 2020 at 2:20 PM David Sterba <dsterba@suse.cz> wrote:
> > >
> > > On Thu, Mar 05, 2020 at 11:57:52AM +0000, Filipe Manana wrote:
> > > > So this actually isn't safe.
> > > >
> > > > It can bring back the race that leads to file extent items with
> > > > overlapping ranges. Not because of the hole detection part but because
> > > > of the part where we copy extent items from the fs/subvolume tree into
> > > > the log tree using btrfs_search_forward(), as we copy all extent
> > > > items, including the ones outside the fsync range - so we could race
> > > > in the same way as we did during hole detection with ordered extent
> > > > completion for ordered extents outside the range.
> > > >
> > > > I'll have to rework this a bit.
> > >
> > > Ok, I'll remove the branch from for-next. Thanks.
> >
> > Wrong thread, the comment was meant for:
> > https://patchwork.kernel.org/patch/11419793/
>
> Saw it just now and taht was a bit wtf if my mail did not make it
> through. So, reflink stays in for-next.

Nah, I just picked the wrong thread. V4 of the reflinks patchset is
good as far as I can tell.
Thanks.