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: [email protected]
Phone: (650) 506-8127
_______________________________________________
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
