On Thu, Jul 30, 2009 at 09:39:17AM +0200, Jim Meyering wrote: > Joel Becker wrote: > > 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. Well, I don't see any reason cp(1) can't take advantage of reflink(2). I just think that cp(1) should look at reflink(2) as an optimization, not a specific methodology. What do I mean? If you want to say "I know what a reflink is, and that's exactly what I want", you want "ln -r". But say you want a "cp --snap" that tries to take a snapshot regardless of the backend. It could use reflink(2) on filesystems that support it, or perhaps a passthrough call to the underlying storage, or who knows what. I can also imagine a "cp --shallow" that is "if you can cow, do it, otherwise do a normal cp". Joel -- "I think it would be a good idea." - Mahatma Ghandi, when asked what he thought of Western civilization Joel Becker Principal Software Developer Oracle E-mail: joel.becker@xxxxxxxxxx Phone: (650) 506-8127 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
