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
next prev parent 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.