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.
