On Tue, Nov 28, 2023 at 09:37:21PM -0800, Darrick J. Wong wrote: > TBH I've been wondering what would happen if we bumped i_mappingseq on > updates of either data or cow fork instead of the shift+or'd thing that > we use now for writeback and/or pagecache write. > > I suppose the nice thing about the current encodings is that we elide > revalidations when the cow fork changes but mapping isn't shared. changed? But yes. > > > > Anyway, I'll have time to go play with that (and further purging of > > > function pointers) > > > > Do we have anything where the function pointer overhead is actually > > hurting us right now? > > Not that I know of, but moving to a direct call model means that the fs > would know based on the iomap_XXX_iter function signature whether or not > iomap needs a srcmap; and then it can modify its iomap_begin function > accordingly. > > Right now all those rules aren't especially obvious or well documented. > Maybe I can convince myself that improved documentation will suffice to > eliminate Ted's confusion. :) Well, with an iter model I think we can actually kill the srcmap entirely, as we could be doing two separate overlapping iterations at the same time. Which would probably be nice for large unaligned writes as the write size won't be limited by the existing mapping only used to read in the unaligned blocks at the beginning end end. > > One thing I'd like to move to is to merge the iomap_begin and iomap_end > > callbacks into one similar to willy's series from 2020. The big > > Got a link to that? I need my memory refreshed, having DROP TABLE MEM2020; > pretty please. https://lore.kernel.org/all/20200811205314.GF6107@magnolia/T/
