bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: BTRFS file clone support for cp


From: Jim Meyering
Subject: Re: BTRFS file clone support for cp
Date: Sun, 26 Jul 2009 08:37:58 +0200

Giuseppe Scrivano wrote:
> Jim Meyering <address@hidden> writes:
>
>> However, but what about cp's --sparse option?
>> btrfs supports sparse files, so this new code will have to
>> honor that.  The trouble is that there is currently no option
>> to say "preserve precisely and only whatever holes are present
>> in src", which is the behavior I would expect from that ioctl.
>
> Yes, sparse files are maintained.

And if a file is only partially sparse, cloning it
produces a file with non-sparse runs of zero bytes.

> $ dd if=/dev/zero of=a bs=1 seek=200M count=0
>
> $ stat a
>   File: `a'
>   Size: 209715200     Blocks: 0          IO Block: 4096   regular file
>   ...
>
> $ ./cp a b
>
> $ stat b
>   File: `b'
>   Size: 209715200     Blocks: 0          IO Block: 4096   regular file
>   ...
>
> The special case to handle differently is --sparse=never.
>
>
>> I am inclined to extend the definition of --sparse=auto (the default)
>> to mean "make as faithful a copy as possible (btrfs clone), and failing
>> that, use the sparse-preserving heuristic".  Then we can use the new
>> ioctl in the default case.  The down side of such a move is that it would
>> induce a subtle change in behavior: whereas before, a partially-sparse
>> file would be copied (assuming btrfs FS src and dest) to a fully-sparse
>> destination, now, you'll get a mirror image, partially-sparse copy.
>
> Right, it will behave differently on different file systems.  What about
> --sparse=always?

If I specify --sparse=always, that means I expect all
long-enough sequences of zeros to be converted to holes in the copy.
Hence with --sparse=always, cp must not use the ioctl, which
would perform no transformation.

>> But seeing as how btrfs is so new, there is little legacy to worry about.
>> And besides, for a command whose job it to copy, a feature to permit
>> more faithful copying is hard to turn down or relegate to non-default
>> status.
>
> ..., a cloned partially-sparse file on btrfs takes less
> space than a fully-sparse copied file.

That is not true.  A fully-sparse file takes less space
than a partially-sparse one.

> IMHO use the btrfs clone method is to prefer in both cases:
> --sparse=auto and --sparse=always.  I think that in any case,
> considering a file system could not support sparse files, --sparse
> should be considered just a "suggestion" and not mandatory, and the
> final decision left to cp.

Adding this optimization should not change the meaning of
--sparse=always.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]