On Fri, Feb 22, 2013 at 09:11:28AM -0800, Mike Power wrote: > I think I have a misconception of what copy on write in btrfs means > for individual files. > > I had originally thought that I could create a large file: > time dd if=/dev/zero of=10G bs=1G count=10 > 10+0 records in > 10+0 records out > 10737418240 bytes (11 GB) copied, 100.071 s, 107 MB/s > > real 1m41.082s > user 0m0.000s > sys 0m7.792s > > Then if I copied this file no blocks would be copied until they are > written. Hence the two files would use the same blocks underneath. > But specifically that copy would be fast. Since it would only need > to write some metadata. But when I copy the file: > time cp 10G 10G2 > > real 3m38.790s > user 0m0.124s > sys 0m10.709s > > Oddly enough it actually takes longer then the initial file > creation. So I am guessing that the long duration copy of the file > is expected and that is not one of the virtues of btrfs copy on > write. Does that sound right?
You probably want cp --reflink=always, which makes a CoW copy of the file's metadata only. The resulting files have the semantics of two different files, but share their blocks until a part of one of them is modified (at which point, the modified blocks are no longer shared). Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- "I don't like the look of it, I tell you." "Well, stop --- looking at it, then."
signature.asc
Description: Digital signature
