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/
