Pádraig Brady wrote: > Giuseppe Scrivano wrote: >> Hello, >> >> the BTRFS file system, avaiable on Linux since its 2.6.29 version, >> supports file cloning. This simple patch adds the support for this >> feature to the cp utility. > > Right, so using the COW feature of BTRFS to speed up copies, > and reduce space by only writing blocks that need to be changed. > Cool! > >>>From deea0ee0c2a521aae5a89d8613f937707d8f0e7b Mon Sep 17 00:00:00 2001 >> From: Giuseppe Scrivano <gscriv...@gnu.org> >> Date: Sat, 25 Jul 2009 16:35:27 +0200 >> Subject: [PATCH] cp: support the btrfs file system clone operation. > > This could apply to `install` also. > >> +#ifdef __linux__ >> + /* Try a btrfs clone operation. If the operation is not supported >> + or it fails then copy the file in the usual way. */ >> + if (!ioctl (dest_desc, 1074041865, source_desc)) >> + copied = true; >> +#endif > > I'm a little worried about doing it unconditionally. > At first I was worried about deferring the copy operation > to the process that's going to be modifying the data. > But then realised going to be reading and writing the data anyway. > One caveat though is, with this scheme it could be reading from > and writing to different parts of a mechanical disk which could > be slower due to seeking. > > Another possible issue with this I can think of is > depending on the modification pattern of the COW files, > the modification processes could fragment the file or > more seriously be given ENOSPC errors.
I hope btrfs takes care of this behind the scene. How does the clone work wrt to space consumed, a la df? If copying a 1GB file this way does not update usage stats to reflect the additional 1GB of space used, ... > One could alleviate the last issues by using fallocate() > on the destination, and patch for which is already written > and hopefully we can get in soon (we're waiting on some > clarifcation of the fallocate() interface). Note the fallocate > patch only calls fallocate() when creating holes is not attempted. > I.E. --sparse=never or --sparse=auto when the disk usage indicates > that no holes are present. > > So perhaps we should hold off on this patch until > the fallocate one goes in also? If all I need to clone a huge file is the inode (and no blocks), then yes, we'll have to wait. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
