|
From: | Ric Wheeler |
Subject: | Re: BTRFS file clone support for cp |
Date: | Thu, 30 Jul 2009 12:28:16 -0400 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Lightning/1.0pre Thunderbird/3.0b2 |
On 07/30/2009 04:40 AM, Pádraig Brady wrote:
Jim Meyering wrote:Joel Becker wrote:On Wed, Jul 29, 2009 at 07:14:37PM +0100, Pádraig Brady wrote: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.Right. It definitely should be in ln anyway.Besides, putting the new behavior on a new option avoids the current semantic change we would otherwise induce in cp.Yes doing reflink() in cp by default currently can be problematic as discussed, especially on mechanical hard disks. Though in future I can see most users of cp preferring reflink() to be done, rather than read()/write(). Ponder...
I think that doing reflink by default would be a horrible idea - one good reason to copy a file is to increase your level of fault tolerance and reflink magically avoids that :-)
reflink is a neat feature, but should be used on purpose in my opinion, ric
In any case putting --link=cow or --reflink or whatever in cp could be very useful for creating writeable snapshot branches. cheers, Pádraig.
[Prev in Thread] | Current Thread | [Next in Thread] |