[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, 02 Aug 2009 23:11:28 +0200 |
Giuseppe Scrivano wrote:
> Jim Meyering <address@hidden> writes:
>
>> I am now convinced that cp's new behavior belongs on
>> a separate option, --reflink (i.e., it should not be the default).
>> Giuseppe, do you feel like adding that option and adjusting your
>> test accordingly?
>
> I attached two separate patches, --reflink option and file-clone test.
> Last versions of btrfs have a bug (I asked on #btrfs and they confirmed
> it), btrfs doesn't use correctly all the free space available. In fact
> I get ENOSPC while in reality only 54% is used. Probably it is better
> to postpone the second patch inclusion after the bug is fixed.
>
> Another note, I changed this line in the NEWS file:
> - "when both the source and destination are on the same btrfs partition."
>
> considering that BTRFS supports multiple devices I am not convinced that
> it is always true, I guess source and destination could be on different
> partitions, though I couldn't find a clear answer on the btrfs wiki to
> this question.
Thanks for working on this.
I would be surprised if a cross-file-system COW is possible.
How about this for NEWS:
cp accepts a new option, --reflink: create a lightweight copy
using copy-on-write (COW). This is currently supported only on
btrfs file systems.
Typically, with a feature like this, if a tool is unable to provide
the functionality implied by the new option, it gives a diagnostic
and exits nonzero. Otherwise, it would be far more work for an
application to determine whether the option was honored.
Deciding whether we also want an option saying
copy-via-COW-if-possible-and-ignore-any-failure can wait,
but I'm leaning away from it for now.
------------------------
With your change, the new reflink member may be used uninitialized
via install and mv. To avoid that, just initialize it to false in
each cp_option_init.
Also, please make cp give a diagnostic when --reflink is used with
--sparse=never or --sparse=always. Then, add this assertion in copy.c:
assert ( ! (x->reflink && x->sparse_mode != SPARSE_AUTO));
>>From d110badaf7583acf957477bc7eda2e212b404343 Mon Sep 17 00:00:00 2001
> From: Giuseppe Scrivano <address@hidden>
> Date: Sat, 1 Aug 2009 19:36:48 +0200
> Subject: [PATCH 1/2] cp: accept the --reflink option
>
> * NEWS: Mention it.
> * doc/coreutils.texi: Likewise.
> * src/copy.h (struct cp_options): New member reflink.
> * src/copy.c (usage): Likewise.
> (copy_reg): If reflink is true try to clone the file.
> (main): Check for --reflink.
> (cp_option_init): By default set reflink to false.
> ---
> NEWS | 4 ++--
> doc/coreutils.texi | 9 +++++++++
> src/copy.c | 5 +++--
> src/copy.h | 3 +++
> src/cp.c | 10 +++++++++-
Re: BTRFS file clone support for cp, Pádraig Brady, 2009/08/10