On Fri, May 26, 2023 at 01:10:43AM -0700, Christoph Hellwig wrote: > 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.
wow, yeah, that is not how that is supposed to work...
