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.
