Joel Becker wrote: > On Wed, Jul 29, 2009 at 07:14:37PM +0100, Pádraig Brady wrote: >> Chris Mason wrote: >> > On Wed, Jul 29, 2009 at 03:14:49PM +0100, Pádraig Brady wrote: >> >> >> >> We may need to play around with fallocate() >> >> if we want to get back to the original >> >> cp semantics of actually allocating space >> >> on the file system for the new file. >> > >> > Well, best to just use the original cp code. I was talking with >> > Giuseppe about this as well, I think we should the option to do regular >> > cp via a flag. >> >> Right. Well we can turn off this cloning by doing --sparse={never,always} >> but that has side effects. If we need an option then maybe we should have >> it turn on cloning rather than restore default cp behaviour? >> The side effects I thought of earlier, of COW without corresponding >> allocation >> were possible fragmentation on write or unexpected/mishandled ENOSPC. >> Also for endangered mechanical disks, subsequent processing could >> be slowed as the head seeks between the old and new data to be copied. >> Perhaps these are a small price to pay, especially considering that >> solid state disks will only be affected by the write()=ENOSPC issue. >> >> At the moment we have these linking options: >> >> cp -l, --link #for hardlinks >> cp -s, --symbolic-link #for symlinks >> >> So perhaps we should support: >> >> cp --link={soft,hard,cow} >> for symlink(), link() and reflink() respectively? >> I.E. link to the name, inode or extents respectively. > > I've cooked up 'ln -r' for reflinks, which works for ln(1) but > not for cp(1).
Thanks. I haven't looked, but after reading about the reflink syscall [http://lwn.net/Articles/332802/] had come to the same conclusion: this feature belongs with ln rather than with cp. Besides, putting the new behavior on a new option avoids the current semantic change we would otherwise induce in cp. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils