On Thu, Jul 19, 2018 at 4:54 PM, Josef Bacik <jo...@toxicpanda.com> wrote: > 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,
On first though, it seems to be the simplest and sanest solution :) Thanks. > > Josef -- Filipe David Manana, “Whether you think you can, or you think you can't — you're right.” -- 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