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, 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 +++++++++-




reply via email to

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