A question about subvolumes

A question about subvolumes

[Bob Williams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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?

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
- -- 
Bob Williams
System:  Linux 3.11.10-17-desktop
Distro:  openSUSE 13.1 (x86_64) with KDE Development Platform: 4.13.2
Uptime:  06:00am up 5 days 20:14, 3 users, load average: 0.00, 0.04, 0.08
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlO2vGQACgkQ0Sr7eZJrmU6CPACgoLTFUxx68+z/H30C5wd/MPe4
6rcAoKpqxoETgkbgMd+MAbHEL7BWpLBs
=Cbmm
-----END PGP SIGNATURE-----

Re: A question about subvolumes

[Goffredo Baroncelli]

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

Re: A question about subvolumes

[Bob Williams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/07/14 21:38, Goffredo Baroncelli wrote:
> 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.
> 
> 
Thank you, Goffredo. As the current /home/bob is not a subvolume, but
a regular linux directory/folder, will the "cp --reflink" still carry
the same speed advantage?

In other words, using your example above, will this work:

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


- -- 
Bob Williams
System:  Linux 3.11.10-17-desktop
Distro:  openSUSE 13.1 (x86_64) with KDE Development Platform: 4.13.2
Uptime:  06:00am up 5 days 20:14, 3 users, load average: 0.00, 0.04, 0.08
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlO3F24ACgkQ0Sr7eZJrmU5UaACfcxJObM9sEzaRIoDGBhXCsWXz
lb4An3OwTzXu/l4r/IhT1u+DbLcVPg3h
=S0Hg
-----END PGP SIGNATURE-----

Re: A question about subvolumes

[Goffredo Baroncelli]

On 07/04/2014 11:06 PM, Bob Williams wrote:
> On 04/07/14 21:38, Goffredo Baroncelli wrote:

> 
> Thank you, Goffredo. As the current /home/bob is not a subvolume, but
> a regular linux directory/folder, will the "cp --reflink" still carry
> the same speed advantage?
> 
> In other words, using your example above, will this work:
> 
> 	# cp --reflink -R normal_directory-A/* subvolume-B/
> 	# rm -rf normal_directory-A/

Yes.

If you want to move (or copy) files between subvolume, cp --reflink is faster.


I have to point out that the "--reflink" is only an internal detail. The two file are logically separated: if you after the copy change the source, the destination is unaffected.

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

Re: A question about subvolumes

[Bob Williams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/07/14 07:27, Goffredo Baroncelli wrote:
> On 07/04/2014 11:06 PM, Bob Williams wrote:
>> On 04/07/14 21:38, Goffredo Baroncelli wrote:
> 
>> 
>> Thank you, Goffredo. As the current /home/bob is not a
>> subvolume, but a regular linux directory/folder, will the "cp
>> --reflink" still carry the same speed advantage?
>> 
>> In other words, using your example above, will this work:
>> 
>> # cp --reflink -R normal_directory-A/* subvolume-B/ # rm -rf 
>> normal_directory-A/
> 
> Yes.
> 
> If you want to move (or copy) files between subvolume, cp
> --reflink is faster.
> 
> 
> I have to point out that the "--reflink" is only an internal 
> detail. The two file are logically separated: if you after the
> copy change the source, the destination is unaffected.
> 
Many thanks. Conversion of /home/bob to a subvolume completed
uneventfully. :-) And very quickly, considering it is ~500GB. I have
made a note of that --reflink option.

Bob
- -- 
Bob Williams
System:  Linux 3.11.10-17-desktop
Distro:  openSUSE 13.1 (x86_64) with KDE Development Platform: 4.13.2
Uptime:  06:00am up 6 days 20:14, 4 users, load average: 0.02, 0.18, 0.25
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlO35NAACgkQ0Sr7eZJrmU6YWgCgiriAUJF8Ee01ckev67fBTe6P
/WIAnjs2DnzqPU+nUFhCiyN4K212n893
=gSrD
-----END PGP SIGNATURE-----

Re: A question about subvolumes

[Austin S Hemmelgarn]

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

On 07/05/2014 07:43 AM, Bob Williams wrote:
> On 05/07/14 07:27, Goffredo Baroncelli wrote:
>> On 07/04/2014 11:06 PM, Bob Williams wrote:
>>> On 04/07/14 21:38, Goffredo Baroncelli wrote:
> 
>>>
>>> Thank you, Goffredo. As the current /home/bob is not a
>>> subvolume, but a regular linux directory/folder, will the "cp
>>> --reflink" still carry the same speed advantage?
>>>
>>> In other words, using your example above, will this work:
>>>
>>> # cp --reflink -R normal_directory-A/* subvolume-B/ # rm -rf 
>>> normal_directory-A/
> 
>> Yes.
> 
>> If you want to move (or copy) files between subvolume, cp
>> --reflink is faster.
> 
> 
>> I have to point out that the "--reflink" is only an internal 
>> detail. The two file are logically separated: if you after the
>> copy change the source, the destination is unaffected.
> 
> Many thanks. Conversion of /home/bob to a subvolume completed
> uneventfully. :-) And very quickly, considering it is ~500GB. I have
> made a note of that --reflink option.
> 
> 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
> 

I'm pretty certain that recent versions of the GNU Coreutils will
automatically try a reflink for cp if the underlying filesystem is
BTRFS.  I'm not 100% certain about this as I've just aliases cp to 'cp
--reflink=auto' on all my systems.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2967 bytes --]

Re: A question about subvolumes

[Chris Samuel]

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

On Sat, 5 Jul 2014 12:06:18 PM Austin S Hemmelgarn wrote:

> I'm pretty certain that recent versions of the GNU Coreutils will
> automatically try a reflink for cp if the underlying filesystem is
> BTRFS.  I'm not 100% certain about this as I've just aliases cp to 'cp
> --reflink=auto' on all my systems.

Doesn't appear to be the case in the current git I'm afraid.

http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/cp.c

You could choose to patch cp.c to change:

  x->reflink_mode = REFLINK_NEVER;

to:

  x->reflink_mode = REFLINK_AUTO;

to change the default should you wish to.

All the best,
Chris
-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 482 bytes --]