All of lore.kernel.org
 help / color / mirror / Atom feed
From: Goffredo Baroncelli <kreijack@libero.it>
To: Bob Williams <linux@barrowhillfarm.org.uk>, linux-btrfs@vger.kernel.org
Subject: Re: A question about subvolumes
Date: Fri, 04 Jul 2014 22:38:33 +0200	[thread overview]
Message-ID: <53B710C9.9020601@libero.it> (raw)
In-Reply-To: <53B6BC65.3080302@barrowhillfarm.org.uk>

On 07/04/2014 04:38 PM, Bob Williams wrote:
> I have a disc formatted as btrfs, on which is mounted /home.
> 
> /home/bob is a regular directory.
> 
> /home/bob/Documents is a btrfs subvolume
> 
> /home is btrfs root
> 
> If I do
> 
> # mv /home/bob /home/bob_original
> # btrfs subvolume create /home/bob
> # mv /home/bob_original/* /home/bob/
> # rm /home/bob_original
> 
> will the original subvolume /home/bob/Documents survive this
> operation, and will it now exist as a subvolume under the new
> subvolume /home/bob?

Yes. 

A subvolume is a way to partition a btrfs file-system. You can think a subvolume like a filesystem. 
For objects like files and directory a move command between *different* subvolumes is equal to a copy+remove. If fact is like you are moving data between different file-systems.

Instead moving a subvolume  in *its btrfs filesystem* is a cheap operation (is like moving a link); this is true even if you move a subvolume between different subvolumes.

To increase the speed when you move files between subvolumes (of the *same* btrfs filesystem), you could do a "cp --reflink" + "rm" instead of a "mv"; eg

	# mv subvolume-A/* subvolume-B/

is equal to

	# cp -rf  subvolume-A/* subvolume-B/
	# rm -rf subvolume-A/*

but 
	# cp --reflink -R  subvolume-A/* subvolume-B/
	# rm -rf subvolume-A/

is faster  because "cp --reflink" shared the data between source and destination. This means that you are doing a copy (and a delete) of metadata only.




> 
> I realise it's best to create subvolumes progressively from the top of
> the filesystem tree, but this system originated as an ext4fs which was
> migrated to btrfs, and some sensible things got missed in all the
> excitement. ;-)
> 
> Bob
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

  reply	other threads:[~2014-07-04 20:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-04 14:38 A question about subvolumes Bob Williams
2014-07-04 20:38 ` Goffredo Baroncelli [this message]
2014-07-04 21:06   ` Bob Williams
2014-07-05  6:27     ` Goffredo Baroncelli
2014-07-05 11:43       ` Bob Williams
2014-07-05 16:06         ` Austin S Hemmelgarn
2014-07-05 23:49           ` Chris Samuel

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=53B710C9.9020601@libero.it \
    --to=kreijack@libero.it \
    --cc=kreijack@inwind.it \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux@barrowhillfarm.org.uk \
    /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.