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@xxxxxxx> 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.
