On Mon, Oct 15, 2018 at 10:13:17AM -0700, Darrick J. Wong wrote: > > RFR_TO_SRC_EOF is checked in generic_remap_file_range_prep, > > so the file system should know about it Also looking at it again now > > it seems entirely superflous - we can just pass down then len == we > > use in higher level code instead of having a flag and will side step > > the issue here. > > I'm not a fan of hidden behaviors like that, particularly when we > already have a flags field where callers can explicitly ask for the > to-eof behavior. This just means we have a flag to mean ken is 0 and needs to be filled, rather than encoding that in the field itself. If you fell better we can replace 0 with 0xffffffff and still encode it in the field. > > RFR_CAN_SHORTEN is advisory as no one has to shorten, but that can > > easily be solved by including it everywhere. > > CAN_SHORTEN isn't included everywhere Include it everywhere as in allow it in ever ->remap_file instance. > I sort of thought about introducing a new copy_file_range flag that > would just do deduplication and allow for opportunistic "dedup as much > as you can" but ... meh. Maybe I'll just drop the patch instead; we can > revisit that when anyone wants a better dedupe interface. Sounds fine to me. The btrfs ioctl is really ugly, but then again there is no pressing need for something better.
