On Tue, May 08, 2018 at 06:02:42AM +0200, Christoph Hellwig wrote: > On Tue, May 08, 2018 at 09:16:46AM +1000, Dave Chinner wrote: > > 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.... > > They can just use SEEK_HOLE/DATA and just copy the chunk they care > about. Especially as they already have the SEEK_HOLE/DATA logic > for the plain old copy anyway Well, you think they would given what we've told them in the past about using fiemap for finding holes and the potential for data corruption it comes along with. But - as I found out recently - cp is still using fiemap to find holes, not SEEK_HOLE/DATA. See: https://github.com/coreutils/coreutils/blob/master/src/extent-scan.c > - that is the only thing they have > to create holes in the destination file to start with. Nevermind > that a file system with inline dedup will happily create holes for > them underneath. Yup, I know. However, it's not me that I'm suggesting we do this for.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
