Andi Kleen wrote: > Jim Meyering <j...@meyering.net> writes: >> 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. > > cp already has -l so it would make sense to extend that too. > >> Besides, putting the new behavior on a new option avoids >> the current semantic change we would otherwise induce in cp. > > I don't see how semantics change in a user visible way.
I was thinking that doing reflink() in cp has the following user visible advantages/disadvantages: Advantages: very quick copy less space used Disadvantages: disk head seeking deferred to modification process possible fragmentation on write possible ENOSPC on write The disk head seeking issue will go away with time. I'm not sure if the other disadvantages exist or whether they could be alleviated with fallocate() or something. cheers, Pádraig. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
