All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert White <rwhite@pobox.com>
To: Shriramana Sharma <samjnaa@gmail.com>,
	Hugo Mills <hugo@carfax.org.uk>,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Moving contents from one subvol to another
Date: Sat, 29 Nov 2014 09:07:05 -0800	[thread overview]
Message-ID: <5479FD39.6030208@pobox.com> (raw)
In-Reply-To: <CAH-HCWWh02invDCdx4-bPORdg4r39efsW=buKXTVtfspSQ9sVA@mail.gmail.com>

On 11/29/2014 07:15 AM, Shriramana Sharma wrote:
> On Sat, Nov 29, 2014 at 7:58 PM, Hugo Mills <hugo@carfax.org.uk> wrote:
>>     The latest version of mv should be able to use CoW copies to make
>> it more efficient. It has a --reflink option, the same as cp. Note
>> that you can't make reflinks crossing a mount boundary, but you can do
>> so crossing a subvolume boundary (as you're doing here).

One thing to keep in mind is that mv, when crossing any of these 
boundaries degenerates to a copy-and-remove operation and _none_ of the 
source files will be removed until _all_ of the files have been copied. 
If any of the copy operations fail the removes will not take place at 
all. It would only take a couple large NOCOW files to put you over a 
limit somewhere.

So if you get to an out-of-space condition mid-move you are going to 
have to disentangle your stuff by hand anyway.

If you are consolidating sub-volumes (as per the original question) on a 
"nearly full" drive you may want to do it all long-hand with a script 
moving various chunks or something instead of just trying a move/copy of 
"cp --reflinks /vol1/* /vol2/" (same for mv when you get that --reflinks 
revision).

ASIDE: Also be aware that such a moment would be the perfect time to 
consider compression and so on. A regular copy (non reflinks) will apply 
the currently selected compress= regime (and reconsider sparsity etc) in 
a way that the move will not.  e.g. once you decide to do intrusive 
maintenance you might be well served by taking the extra time to 
restructure your storage. 8-)



  reply	other threads:[~2014-11-29 17:07 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-29 14:21 Moving contents from one subvol to another Shriramana Sharma
2014-11-29 14:28 ` Hugo Mills
2014-11-29 15:15   ` Shriramana Sharma
2014-11-29 17:07     ` Robert White [this message]
2014-11-30  3:53       ` Shriramana Sharma
2014-11-30 13:04         ` Shriramana Sharma

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=5479FD39.6030208@pobox.com \
    --to=rwhite@pobox.com \
    --cc=hugo@carfax.org.uk \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=samjnaa@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.