On Tue, Sep 03, 2019 at 09:05:36AM -0500, Goldwyn Rodrigues wrote: > On 18:31 02/09, Christoph Hellwig wrote: > > On Sun, Sep 01, 2019 at 03:08:23PM -0500, Goldwyn Rodrigues wrote: > > > --- a/include/linux/iomap.h > > > +++ b/include/linux/iomap.h > > > @@ -37,6 +37,7 @@ struct vm_fault; > > > #define IOMAP_MAPPED 0x03 /* blocks allocated at @addr */ > > > #define IOMAP_UNWRITTEN 0x04 /* blocks allocated at @addr in unwritten state */ > > > #define IOMAP_INLINE 0x05 /* data inline in the inode */ > > > +#define IOMAP_COW 0x06 /* copy data from srcmap before writing */ > > > > I don't think IOMAP_COW can be a type - it is a flag given that we > > can do COW operations that allocate normal written extents (e.g. for > > direct I/O or DAX) and for delayed allocations. > > > > Ah.. we have come a full circle on this one. From going to a flag, to a type, > and now back to flag. Personally, I like COW to be a flag, because we are > doing a write, just doining extra steps which should be a flag. > From previous objections, using two iomaps should help the cause and we > can not worry about bloating. Heh, ok, let's do a cow flag. Thank you for driving the consensus. :) (Sorry it took so long while we went around in circles.) Also, I'm going on vacation starting Friday at noon PDT, so please have the three patches that touch fs/iomap/ in before 7am Friday. (Assuming you're not making drastic changes to your iomap changes, they've tested ok so far.) --D > > -- > Goldwyn
