On Thu, Jul 19, 2018 at 04:21:58PM +0100, Filipe Manana wrote: > On Thu, Jul 19, 2018 at 3:50 PM, Josef Bacik <jo...@toxicpanda.com> wrote: > > Since we've changed the fsync() path to always run ordered extents > > before doing the tree log we no longer need to take the dio_sem in the > > tree log path. This gets rid of a lockdep splat that I was seeing with > > the AIO tests. > > So actually, we still need it (or some other means of sync). > Because even after the recent changes to fsync, the fast path still > logs extent items based on the extent maps, and the dio write path > creates first the extent map and then the ordered extent. > So the old problem can still happen between concurrent fsync and > lockless dio write, where fsync logs an extent item for an extent map > whose ordered extent we never waited for. > The solution prior to the introduction of dio_sem solved this - make > the dio write create first the ordered extent, and, only after it, > create the extent map. >
Oooh balls I see. This is still a problem even if we add the ordered extent first, because we can easily just start the lockless dio write after we've waited for ordered extents, so the order we create the extent map and ordered extent don't actually matter. We still have this lockdep thing, I think we just move the dio_sem to the start of fsync, if we're fsyncing you just don't get to do lockless dio writes while we're doing the fsync. What do you think? Thanks, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
