Hey Pádraig. On Sat, 2015-11-07 at 16:15 +0000, Pádraig Brady wrote: > The reason --reflink=auto is not default for cp is because it > changes the end state of the copy. In this case the main issue is > that later changes to the file may give ENOSPC or result in > fragmentation. Sure..
> Now I do agree that you'll get the same issue if you later fill holes > in the file, or change data on deduplicating file systems/devices, > ... That's the argument which may justify to make the default reflink=auto - these issues may happen anyway, and they're core part of CoW filesystems. So everyone who uses them, must expect this,... or should avoid them. > So perhaps we should just consider reflink as an implementation > option, > and have a higher level --prealloc or whatever for those who care > about that. > I.E. instead have cp to do the lightest weight copy possible, > and have --prealloc etc. change that for the edge cases that care > (with the caveat that existing systems may already be depending > on the current non CoW default behavior). Whatever one does, there will surely be at least one person that complains ;-) But your idea doesn't sound bad. > There is work currently in the kernel for providing > vfs_copy_file_range() > which will copy at the lowest level possible. That will do in > prefered order; > server copy offload, SCSI COPY, reflink on BTRFS (or XFS etc. when > available), > or splice at the VFS level. If cp calls into that by default then > you get your desired behavior by default. I'm looking at that logic > at present, and hope to have it in the next coreutils release, > which would be v9.0 since there are other invasive changes being > considered. Looking forward to it. So do you see it coming that this is actually "solved" (meaning refcopy works per default out of the box for e.g. btrfs users) upstream ... or is it worth to look into making it configurable at the distro level, as I proposed above? Thanks, Chris.
smime.p7s
Description: S/MIME cryptographic signature
