Re: BTRFS file clone support for cp

[Pádraig Brady]

Giuseppe Scrivano wrote:
> Hi Pádraig,
> 
> thanks for the comments.
> 
> Pádraig Brady <address@hidden> writes:
> 
>> # 300MB seems to be the minimum size for a btrfs with default
>> parameters.
> 
> Actually, it seems the minimum space required is 256MB.  Using a 255MB
> image I get: "device btrfs.img is too small (must be at least 256 MB)"

I tried that with my version of btrfs but still got the "too small" error.
I probably did something silly.

>> # FIXME: use `truncate --allocate` when it becomes available, which
>> # may allow unmarking this as an expensive test.
> 
> Are you sure that this feature will make the test less expensive?  Still
> the test files must be written there, so in the best case (considering
> the fallocate done in 0s) only the dd cost will be saved but still it
> looks like an expensive test.

Well with fallocate() I expect only the file system meta data
to be modified, thus obviating moving any zeros around.
But you're right that the mkfs will probably have to write lots of data.

> In the version I attached, I am using a sparse file (truncate --size)
> and it seems to work fine.  Is it correct or am I missing something?

Nope, good idea! I guess the mkfs writes all the blocks anyway
as mentioned above, but this is now done only once.

> I haven't looked yet but probably there are other tests that can take
> advantage of sparse files instead of using "dd".
> 
> I am also considering the Jim's note doing the umount in the cleanup_

I noticed that also but got distracted :p

> diff --git a/tests/cp/file-clone b/tests/cp/file-clone
> +
> +require_root_
> +require_sparse_support_
> +#expensive_

That comment is just for testing I presume?
Note you can run a single expensive test like:
(cd tests && make check TESTS=cp/file-clone VERBOSE=yes RUN_EXPENSIVE_TESTS=yes)

cheers,
Pádraig.