On Mon, Feb 18, 2019 at 10:09:42AM +0100, Christoph Hellwig wrote: > On Fri, Feb 15, 2019 at 03:32:25PM -0800, Darrick J. Wong wrote: > > I /think/ the way that this series (+ Brian's before that) solve the > > truncate/writeback race is that we now only convert existing delalloc > > reservations to real extents when we're preparing to do writeback; > > _writepage_map only cares about the mapping of the offset_fsb that it > > happens to be looping right now (because the page lock serializes with > > page cache truncate/punch); and we use the new sequence counters for > > both the data and cow forks to decide when our cached mapping might be > > invalid and therefore we need to get a new mapping? > > Well, we already tried to do that before, we just weren't all that good > at it. The big difference is that the delalloc conversion now doesn't > blindly reuse the range looked up a long time before under a different > ilock critical section, but instead just uses that as a hint and > only converts the extent that the writeback offset falls into, and > only does so if it actually still is in delalloc state. Got it. I'll pull this in if I don't hear any loud yelling. :) (FWIW it tested ok over the weekend.) --D
