On Wed, Jul 29, 2009 at 12:10:14PM -0400, Chris Mason wrote: > On Wed, Jul 29, 2009 at 03:14:49PM +0100, Pádraig Brady wrote: > > Chris Mason wrote: > > > On Tue, Jul 28, 2009 at 10:06:35PM +0200, Giuseppe Scrivano wrote: > > >> > > >> I can't replicate it now, all tests I am doing report that blocks used > > >> before and after the clone are the same. Probably yesterday the > > >> difference I noticed was in reality the original file flushed to the > > >> disk. > > > > > > The clone will use some additional space for the metadata required to > > > point to the cloned blocks. It isn't exactly O(1) it is O(metadata for > > > the file). > > > > Thanks for the clarification Chris. > > So the just committed change in cp will > > link the destination file to the extents of the source. > > > > 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. > > There will soon be a reflink system call that can be used on ocfs2 and > btrfs as well. Thanks for adding this to glibc!
Um, cp, not glibc, sorry ;) -chris _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
