On Tue, May 15, 2018 at 10:16:52AM +0200, Andreas Gruenbacher wrote: > > Yes. And from a quick look we can easily handle "stuffed" aka inline > > data with the existing architecture. We just need a new IOMAP_INLINE > > flag for the extent type. Details will need to be worked out how to > > pass that data, either a struct page or virtual address should probably > > do it. > > This is about data journaling, it has nothing to do with "stuffed" > files per se. With journaled data writes, we need to do some special > processing for each page so that the page ends up in the journal > before it gets written back to its proper on-disk location. It just > happens that since we need these per-page operations anyway, the > "unstuffing" and "re-stuffing" nicely fits in those operations as > well. Your series makes two uses of the callbacks - one use case is to deal with inline data. The right way to deal with that is to make inline data an explicit iomap type (done in my next posting of the buffer head removal series), and then have iomap_begin find the data, kmap it and return it in the iomap, with iomap_end doing any fixups. For the data journaing I agree that we need a post-write per page callout, but I think this should be just a simple optional callout just for data journaling, which doesn't override the remaining write_end handling. > Been there. An earlier version of the patches did have a separate > stuffed write path and the unstuffing and re-stuffing didn't happen in > those per-page operations. The result was much messier overall. Pointer, please.
