On Wed, May 22, 2019 at 03:14:47PM -0500, Goldwyn Rodrigues wrote: > On 9:51 21/05, Darrick J. Wong wrote: > > On Mon, Apr 29, 2019 at 12:26:35PM -0500, Goldwyn Rodrigues wrote: > > We cannot use @inline_data to convey the source address. @inline_data > > (so far) is used to point to the in-memory representation of the storage > > described by @addr. For data writes, @addr is the location of the write > > on disk and @inline_data is the location of the write in memory. > > > > Reusing @inline_data here to point to the location of the source data in > > memory is a totally different thing and will likely result in confusion. > > On a practical level, this also means that we cannot support the case of > > COW && INLINE because the type codes collide and so would the users of > > @inline_data. This isn't required *right now*, but if you had a pmem > > filesystem that stages inode updates in memory and flips a pointer to > > commit changes then the ->iomap_begin function will need to convey two > > pointers at once. > > > > So this brings us back to Dave's suggestion during the V1 patchset > > review that instead of adding more iomap flags/types and overloading > > fields, we simply pass two struct iomaps into ->iomap_begin: > > Actually, Dave is the one who suggested to perform it this way. > https://patchwork.kernel.org/comment/22562195/
My first suggestion was to use two iomaps. This suggestion came later, as a way of demonstrating that a different type could be used to redefine what ->inline_data was used for, if people considered that an acceptible solution. What was apparent from other discussions in the thread you quote was that using two iomaps looked to be the better, more general approach to solving the iomap read-modify-write issue at hand. Cheers, Dave. -- Dave Chinner da...@fromorbit.com _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
