Why subvolume and not just volume?

Why subvolume and not just volume?

[Martin]

Hi,

Does anyone know the reason subvolumes are not called just volumes? I
mean, the top subvolume is not called a volume, so there is nothing to
be "sub" of.

Also, what is the penalty of a subvolume compared to a directory? From
a design perspective, couldn't all directories just be subvolumes?

Martin

Re: Why subvolume and not just volume?

[Qu Wenruo]

Martin wrote on 2015/08/05 09:06 +0200:
> Hi,
>
> Does anyone know the reason subvolumes are not called just volumes? I
> mean, the top subvolume is not called a volume, so there is nothing to
> be "sub" of.
Because normally a volume is referred as a complete filesystem.
So from this respect, subvolume is not a full filesystem, it still need 
a lot of extra data from other trees to build its contents.

So, that's why there is "sub" prefix.
Although it acts much like a volume as it can be mounted like a 
filesystem, but it's still not a full filesystem.
>
> Also, what is the penalty of a subvolume compared to a directory? From
> a design perspective, couldn't all directories just be subvolumes?
Yes, subvolume has its overhead, and when it comes as many as 
directories, the overhead won't be small.

The overhead that I can remember is shown below.
Use empty tree as an example for its size, and default mkfs options.
The '+' after number means it will increase with snapshots

1) Empty tree block: 16K
    Of course takes more if its child file/dir grows
2) ROOT_ITEM in tree root: 439bytes
3) ROOT_BACKREF in tree root: 22+bytes
5) extent backref for tree block:
     33+bytes for skinny metadata
     53+bytes without skinny metadata

Alone with other trees like log tree, one for each subvolume if fsync is 
called.

Not to mention other run-time overhead.
For example, to search a inode in one subvolume.
Search_slot would be enough to find the INODE_ITEM.

But to search a inode across subvolume boundary, need to first found the 
subvolume boundary and loop until we reach the subvolume containing the 
inode, then do the above search_slot to locate the INODE_ITEM.

Although the overhead is already small, but not that small to make all 
directories to be subvolume.

Thanks,
Qu
>
> Martin
> --
> 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
>

Re: Why subvolume and not just volume?

[David Sterba]

On Wed, Aug 05, 2015 at 09:06:40AM +0200, Martin wrote:
> Also, what is the penalty of a subvolume compared to a directory? From
> a design perspective, couldn't all directories just be subvolumes?

They could, but this would bring severe performance drop.

* creating a subvolume implies a transaction commit
* the subvolumes act like a mountpoint boundary so it needs to resolve
  the next subvolume root before directory traversal can descend to it

You can try to create a deep hierarchy of directories and then do the
same with subvolumes. The difference is too big for practical purposes.

Re: Why subvolume and not just volume?

[Duncan]

Martin posted on Wed, 05 Aug 2015 09:06:40 +0200 as excerpted:

> [W]hat is the penalty of a subvolume compared to a directory? From a
> design perspective, couldn't all directories just be subvolumes?

In addition to the performance issues mentioned by others, there's at 
least one further practical reason as well.

Snapshots stop at subvolume boundaries.  It's thus quite useful to use 
subvolumes to delineate the limits of the snapshot, saying, in effect, 
snapshot this dir (which happens to be a subvol not just a normal dir) 
recursively, but don't snapshot the subtree starting with this nested 
subdir (which again is a (different) subvol).

Subvols act very much like directories, it is true.  But they have a few 
additional properties and different behaviors, and it is the distinction 
between directories and subvols that makes them valuable /as/ subvols.  
Without a distinction, the whole reason to have subvols as a separate 
feature vanishes.

(FWIW, the first systemd release, v219, to use btrfs subvolume in place 
of directories found out some of the behavior differences the hard way.  
Where it was previously doing mkdir, which returns success if the 
directory is already there, critical for a root filesystem keep read-only 
mounted by default, but with the required directories already created, on 
btrfs it tried to create a subvolume instead, which fails if there's a 
directory already there, particularly if it's a read-only mount.  So the 
behavior creating a subvol differs from that of creating a subdir, and 
systemd's tmpfiles service was failing on read-only btrfs mounts as a 
result, while it previously succeeded, when it was only trying to create 
directories, which already existed.  Oops!  The bug was fixed in v221, 
but the experience does illustrate that while subvolumes behave in /many/ 
ways like subdirs, there are indeed small differences in behavior that 
can leap up and bite the unwary.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: Why subvolume and not just volume?

[Austin S Hemmelgarn]

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

On 2015-08-06 03:23, Duncan wrote:
> Martin posted on Wed, 05 Aug 2015 09:06:40 +0200 as excerpted:
>
>> [W]hat is the penalty of a subvolume compared to a directory? From a
>> design perspective, couldn't all directories just be subvolumes?
>
> In addition to the performance issues mentioned by others, there's at
> least one further practical reason as well.
>
> Snapshots stop at subvolume boundaries.  It's thus quite useful to use
> subvolumes to delineate the limits of the snapshot, saying, in effect,
> snapshot this dir (which happens to be a subvol not just a normal dir)
> recursively, but don't snapshot the subtree starting with this nested
> subdir (which again is a (different) subvol).
>
And for some people, this is very useful functionality.  I use it to 
specifically exclude subsets of trivially reproducible data from backups 
(for example, I always clone public git repositories into individual 
subvolumes, and keep my local copy of the Portage tree on a separate one 
(when it isn't on a separate filesystem that is)).


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