On Thu, May 25, 2023 at 07:20:46PM -0400, Kent Overstreet wrote: > > > I'm absolutely not in favour to add workarounds for thes kind of locking > > > problems to the core kernel. I already feel bad for allowing the > > > small workaround in iomap for btrfs, as just fixing the locking back > > > then would have avoid massive ratholing. > > > > Please let me know when those btrfs changes are in a presentable shape ... > > I would also be curious to know what btrfs needs and what the approach > is there. btrfs has the extent locked, where "extent locked" is a somewhat magic range lock that actually includes different lock bits. It does so because it clears the page writeback bit when the data made it to the media, but before the metadata required to find it is commited, and the extent lock prevents it from trying to do a readpage on something that has actually very recently been written back but not fully commited. Once btrfs is changed to only clear the page writeback bit once the write is fully commited like in other file systems this extra level of locking can go away, and there are no more locks in the readpage path that are also taken by the direct I/O code. With that a lot of code in btrfs working around this can go away, including the no fault direct I/O code.
