[Top][All Lists]
[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.
- BTRFS file clone support for cp, Giuseppe Scrivano, 2009/07/25
- Re: BTRFS file clone support for cp, Jim Meyering, 2009/07/25
- Re: BTRFS file clone support for cp, Giuseppe Scrivano, 2009/07/25
- Re: BTRFS file clone support for cp, Jim Meyering, 2009/07/25
- Re: BTRFS file clone support for cp, Giuseppe Scrivano, 2009/07/25
- Re: BTRFS file clone support for cp,
Jim Meyering <=
- Re: BTRFS file clone support for cp, Giuseppe Scrivano, 2009/07/26
- Re: BTRFS file clone support for cp, Jim Meyering, 2009/07/26
- Re: BTRFS file clone support for cp, Giuseppe Scrivano, 2009/07/26
- Re: BTRFS file clone support for cp, Jim Meyering, 2009/07/27
- Re: BTRFS file clone support for cp, Andreas Schwab, 2009/07/27
- Re: BTRFS file clone support for cp, Jim Meyering, 2009/07/28
- Re: BTRFS file clone support for cp, Jim Meyering, 2009/07/29
- Re: BTRFS file clone support for cp, Jim Meyering, 2009/07/29
Re: BTRFS file clone support for cp, Pádraig Brady, 2009/07/26