On Mon, May 07, 2018 at 02:16:38PM +0200, Christoph Hellwig wrote: > On Sun, May 06, 2018 at 09:16:41AM +1000, Dave Chinner wrote: > > > In the patchset description [0], I ask if this should be the default > > > feature (I think it should be) and holes should be converted to zeros as > > > a special flag.. The only argument against it could be that applications > > > are already using this interface, so this would be a change in behavior. > > > > In general, we don't change the behaviour of syscalls after the > > fact. We have flags to control behaviour, so applications that want > > to preserve holes will just have to be changed to use that flag. > > copy_file_range isn't documented to either preserve or not preserve > holes. And in fact it will preserve holes (or even create new ones) > for any filesystem that implements it as a clone like btrfs or xfs.. Right, but that's the entire problem. And you can't even say it will preserve holes on XFS, because that relies on a filesystem format feature that most users currently don't have enabled. Hence it will be sparse preserving on some XFS filesystems but not on most. This sort of whacky undefined behaviour w.r.t. sparseness was the reason we were given at LSFMM for cp and rsync not implementing copy_file_range() - they could not control it according to the user's direction. Hence my suggestion that we need flags to specifically direct the behaviour of the syscall so that userspace will actually use it.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
