Re: copy on write misconception

[Mike Power <dodtsair@gmail.com>]

On 02/22/2013 09:16 AM, Hugo Mills wrote:
> 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.
>
I see, and it works great:
time cp --reflink=always 10G 10G3

real    0m0.028s
user    0m0.000s
sys    0m0.000s

So from the user perspective I might say I want to opt out of this 
feature not optin.  I want all copies by all applications done as a copy 
on write.  But if my understanding is correct that is up to the 
application being called (in this case cp) and how it in turns makes 
calls to the system.

In short I can't remount the btrfs filesystem with some new args that 
says always copy on write files because that is what it already.

Mike Power