Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Marc MERLIN <marc@merlins.org>
To: Hugo Mills <hugo@carfax.org.uk>, linux-btrfs@vger.kernel.org
Subject: Re: Can moving data to a subvolume not take as long as a fully copy?
Date: Mon, 14 Jan 2013 10:00:41 -0800	[thread overview]
Message-ID: <20130114180041.GC23026@merlins.org> (raw)
In-Reply-To: <20130114174155.GA19051@carfax.org.uk>

[-- Attachment #1: Type: text/plain, Size: 1350 bytes --]

On Mon, Jan 14, 2013 at 05:41:55PM +0000, Hugo Mills wrote:
> On Mon, Jan 14, 2013 at 09:32:50AM -0800, Marc MERLIN wrote:
> > I made a mistake and copied data in the root of a new btrfs filesystem.
> > I created a subvolume, and used mv to put everything in there.
> > Something like:
> > cd /mnt
> > btrfs subvolume create dir
> > mv * dir
> > 
> > Except it's been running for over a day now (ok, it's 5TB of data)
> > 
> > Looks like mv is really copying all the data as if it were an entirely
> > different filesystem.
> > 
> > Is there not a way to short circuit this and only update the metadata?
> 
>    I guess the best way of doing this in this case is to teach mv to
> do cp --reflink=always then unlink the origin.
> 
>    Clearly that won't work over mount boundaries (where a copy of the
> data is the best you're going to get), but that's not what you've got
> here.

Mmmh, this made me think:
It seems that I could have done cp --reflink without duplicating the data
and running out of space.
Then, I could have deleted the originals?

Is that correct?

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 308 bytes --]

  reply	other threads:[~2013-01-14 18:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-14 17:32 Can moving data to a subvolume not take as long as a fully copy? Marc MERLIN
2013-01-14 17:41 ` Hugo Mills
2013-01-14 18:00   ` Marc MERLIN [this message]
2013-01-14 18:13     ` Hugo Mills
2013-01-15  6:48 ` David Brown
2013-01-15 14:49   ` Marc MERLIN
2013-01-15 17:45     ` Mitch Harder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130114180041.GC23026@merlins.org \
    --to=marc@merlins.org \
    --cc=hugo@carfax.org.uk \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox