* What means "top level" in "btrfs subvolume list" ?
@ 2017-09-30 11:57 Goffredo Baroncelli
2017-09-30 14:53 ` Peter Grandi
2017-10-01 7:49 ` Andrei Borzenkov
0 siblings, 2 replies; 5+ messages in thread
From: Goffredo Baroncelli @ 2017-09-30 11:57 UTC (permalink / raw)
To: linux-btrfs
(please ignore my previous email, because I wrote somewhere "top id" instead of "top level")
Hi All,
I am trying to figure out which means "top level" in the output of "btrfs sub list"
ghigo@venice:~$ sudo btrfs sub list /
[sudo] password for ghigo:
ID 257 gen 548185 top level 5 path debian
ID 289 gen 418851 top level 257 path var/lib/machines
ID 299 gen 537230 top level 5 path boot
ID 532 gen 502364 top level 257 path tmp/test1
ID 533 gen 502277 top level 532 path tmp/test1/test2
ID 534 gen 502407 top level 257 path tmp/test1.snap
ID 535 gen 502363 top level 532 path tmp/test1/test3
ID 536 gen 502407 top level 257 path tmp/test1.snap2
ID 537 gen 537132 top level 5 path test
ID 538 gen 537130 top level 537 path test/sub1
The root filesystem is mounted as
mount -o subvol=debian ....
I think that "btrfs sub list" is buggy, and it outputs a "top level ID" equal to the "parent ID" (on the basis of the code). But I am still asking which would be the RIGHT "top level id". My Hypothesis, it should be the ID of the root subvolume ( or 5 if it is not mounted). So the output should be
ghigo@venice:~$ sudo btrfs sub list /
[sudo] password for ghigo:
ID 257 gen 548185 top level 5 path debian
ID 289 gen 418851 top level 257 path var/lib/machines
ID 299 gen 537230 top level 5 path boot
ID 532 gen 502364 top level 257 path tmp/test1
ID 533 gen 502277 top level 257 path tmp/test1/test2
ID 534 gen 502407 top level 257 path tmp/test1.snap
ID 535 gen 502363 top level 257 path tmp/test1/test3
ID 536 gen 502407 top level 257 path tmp/test1.snap2
ID 537 gen 537132 top level 5 path test
ID 538 gen 537130 top level 5 path test/sub1
The subvolumes in the file system (mounted from /debian) are
/ ID = 5
/debian ID = 257
/debian/var/lib/machines ID = 289
/boot ID = 299
/debian/tmp/test1 ID = 532
/debian/tmp/test1/test2 ID = 533
/debian/tmp/test1.snap ID = 534
/debian/tmp/test1/test3 ID = 535
/debian/tmp/test1.snap2 ID = 536
/test ID = 537
/test/sub1 ID = 538
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: What means "top level" in "btrfs subvolume list" ?
2017-09-30 11:57 What means "top level" in "btrfs subvolume list" ? Goffredo Baroncelli
@ 2017-09-30 14:53 ` Peter Grandi
2017-09-30 16:38 ` Andrei Borzenkov
2017-10-02 19:07 ` Goffredo Baroncelli
2017-10-01 7:49 ` Andrei Borzenkov
1 sibling, 2 replies; 5+ messages in thread
From: Peter Grandi @ 2017-09-30 14:53 UTC (permalink / raw)
To: Linux fs Btrfs
> I am trying to figure out which means "top level" in the
> output of "btrfs sub list"
The terminology (and sometimes the detailed behaviour) of Btrfs
is not extremely consistent, I guess because of permissive
editorship of the design, in a "let 1000 flowers bloom" sort
of fashion so that does not matter a lot.
> [ ... ] outputs a "top level ID" equal to the "parent ID" (on
> the basis of the code).
You could have used option '-p' and it would have printed out
both "top level ID" and "parent ID" for extra enlightenment.
> But I am still asking which would be the RIGHT "top level id".
But perhaps one of them is now irrelevant, because 'man btrfs
subvolume says:
"If -p is given, then parent <ID> is added to the output
between ID and top level. The parent’s ID may be used at mount
time via the subvolrootid= option."
and 'man 5 btrfs' says:
"subvolrootid=objectid
(irrelevant since: 3.2, formally deprecated since: 3.10)
A workaround option from times (pre 3.2) when it was not
possible to mount a subvolume that did not reside directly
under the toplevel subvolume."
> My Hypothesis, it should be the ID of the root subvolume ( or
> 5 if it is not mounted). [ ... ]
Well, a POSIX filesystem typically has a root directory, and it
can be mounted as the system root or any other point. A Btrfs
filesystem has multiple root directories, that are mounted by
default "somewhere" (a design decision that I think was unwise,
but "whatever").
The subvolume containing the mountpoint directory of another
subvolume's root directory is is no way or sense its "parent",
as there is no derivation relationship; root directories are
independent of each other and their mountpoint is (or should be)
a runtime entity.
If there is a "parent" relationship that maybe be between
snapshot and origin subvolume (ignoring 'send'/'receive'...),
and I have created a few plain and snapshot subvolumes and I get
this rather "confusing" output from version 4.4 of the 'btrfs'
command:
base# btrfs subvol list -uq -a -p /fs/sda7 | sort -k 6,6n -k 8,8
ID 257 gen 718 parent 5 top level 5 parent_uuid - uuid 2d7b0606-76d9-f24b-8f75-d20a5c0f3521 path =
ID 356 gen 719 parent 5 top level 5 parent_uuid - uuid 9d201029-d2bf-2f43-8381-8c19d090483e path sl1
ID 358 gen 719 parent 5 top level 5 parent_uuid 2d7b0606-76d9-f24b-8f75-d20a5c0f3521 uuid bc0e6a33-b5dc-4d48-b2db-1452b705d227 path sn1
ID 357 gen 715 parent 356 top level 356 parent_uuid - uuid 2abc6399-956d-894f-836b-32eb5b603654 path <FS_TREE>/sl1/sl2
ID 360 gen 718 parent 356 top level 356 parent_uuid 2d7b0606-76d9-f24b-8f75-d20a5c0f3521 uuid ad896822-e9a5-c645-8cfd-0aca7f5a2298 path <FS_TREE>/sl1/sn3
ID 361 gen 719 parent 356 top level 356 parent_uuid bc0e6a33-b5dc-4d48-b2db-1452b705d227 uuid 9c1390d2-e485-cb4a-a41b-670248587bfb path <FS_TREE>/sl1/sn4
ID 359 gen 717 parent 358 top level 358 parent_uuid 2d7b0606-76d9-f24b-8f75-d20a5c0f3521 uuid 72d4f943-2881-6442-b398-2277be8f2fec path <FS_TREE>/sn1/sn2
The "confusion" is that for some subvolumes the "parent" is the
same but the "parent_uuid" is different, and viceversa.
IIRC this has already been mentioned in part elsewhere.
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: What means "top level" in "btrfs subvolume list" ?
2017-09-30 14:53 ` Peter Grandi
@ 2017-09-30 16:38 ` Andrei Borzenkov
2017-10-02 19:07 ` Goffredo Baroncelli
1 sibling, 0 replies; 5+ messages in thread
From: Andrei Borzenkov @ 2017-09-30 16:38 UTC (permalink / raw)
To: Peter Grandi, Linux fs Btrfs
30.09.2017 17:53, Peter Grandi пишет:
>> I am trying to figure out which means "top level" in the
>> output of "btrfs sub list"
>
> The terminology (and sometimes the detailed behaviour) of Btrfs
> is not extremely consistent, I guess because of permissive
> editorship of the design, in a "let 1000 flowers bloom" sort
> of fashion so that does not matter a lot.
>
>> [ ... ] outputs a "top level ID" equal to the "parent ID" (on
>> the basis of the code).
>
> You could have used option '-p' and it would have printed out
> both "top level ID" and "parent ID" for extra enlightenment.
>
How does it explain what "top level" is?
>> But I am still asking which would be the RIGHT "top level id".
>
> But perhaps one of them is now irrelevant, because 'man btrfs
> subvolume says:
>
> "If -p is given, then parent <ID> is added to the output
> between ID and top level. The parent’s ID may be used at mount
> time via the subvolrootid= option."
>
> and 'man 5 btrfs' says:
>
> "subvolrootid=objectid
> (irrelevant since: 3.2, formally deprecated since: 3.10)
> A workaround option from times (pre 3.2) when it was not
> possible to mount a subvolume that did not reside directly
> under the toplevel subvolume."
>
This still does not explain what "top level" in "btrfs sub list" means.
>> My Hypothesis, it should be the ID of the root subvolume ( or
>> 5 if it is not mounted). [ ... ]
>
> Well, a POSIX filesystem typically has a root directory, and it
> can be mounted as the system root or any other point. A Btrfs
> filesystem has multiple root directories, that are mounted by
> default "somewhere" (a design decision that I think was unwise,
> but "whatever").
>
> The subvolume containing the mountpoint directory of another
> subvolume's root directory is is no way or sense its "parent",
> as there is no derivation relationship; root directories are
> independent of each other and their mountpoint is (or should be)
> a runtime entity.
>
With all respect that is not how it looks like. Each subvolume has very
precise relationship to containing subvolume; you can only traverse
subvolumes via this very explicit relationship. The fact that subvolumes
can also be mounted individually on VFS level is rather irrelevant for
filesystem structure.
Whether "parent" is correct name for containing subvolume is of course
subject to opinion, but for me it fits - subvolumes do form a tree and
have very well defined parent/child relationship.
> If there is a "parent" relationship that maybe be between
> snapshot and origin subvolume (ignoring 'send'/'receive'...),
Yes, having the same name for entirely different types of hierarchical
relationships is unfortunate. But it still does not explain what "top
level" means :)
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: What means "top level" in "btrfs subvolume list" ?
2017-09-30 14:53 ` Peter Grandi
2017-09-30 16:38 ` Andrei Borzenkov
@ 2017-10-02 19:07 ` Goffredo Baroncelli
1 sibling, 0 replies; 5+ messages in thread
From: Goffredo Baroncelli @ 2017-10-02 19:07 UTC (permalink / raw)
To: Peter Grandi, Linux fs Btrfs
On 09/30/2017 04:53 PM, Peter Grandi wrote:
>> My Hypothesis, it should be the ID of the root subvolume ( or
>> 5 if it is not mounted). [ ... ]
> Well, a POSIX filesystem typically has a root directory, and it
> can be mounted as the system root or any other point. A Btrfs
> filesystem has multiple root directories, that are mounted by
> default "somewhere" (a design decision that I think was unwise,
> but "whatever").
I agree that the possibility to create a subvolume/snapshot everywhere could create a bit of confusion; i.e. the "mountpoint" of a subvolume after a snapshot is a very strange beast:
ghigo@venice:/tmp$ btrfs sub cre sv1
Create subvolume './sv1'
ghigo@venice:/tmp$ btrfs sub cre sv1/sv2
Create subvolume 'sv1/sv2'
ghigo@venice:/tmp$ btrfs sub snap sv1 sn1
Create a snapshot of 'sv1' in './sn1'
ghigo@venice:/tmp$ ls -lid sn1/
256 drwxr-xr-x 1 ghigo ghigo 6 Oct 2 20:54 sn1/
ghigo@venice:/tmp$ ls -li sn1/
total 0
2 drwxr-xr-x 1 root root 0 Oct 2 20:55 sv2
ghigo@venice:/tmp$ touch sn1/sv2/foo
touch: cannot touch 'sn1/sv2/foo': Permission denied
ghigo@venice:/tmp$ sudo touch sn1/sv2/foo
touch: cannot touch 'sn1/sv2/foo': Permission denied
It seems a directory, but it is not allowed to create file inside (!)
However the user is free to limit itself to create snapshot only under / (rootid==5) :-).
> The subvolume containing the mountpoint directory of another
> subvolume's root directory is is no way or sense its "parent",
> as there is no derivation relationship; root directories are
> independent of each other and their mountpoint is (or should be)
> a runtime entity.
This is true. However I think that "btrfs fi list" was designed to show where subvolumes (or snapshots) are, for two reasons:
1) avoid to search trough all the filesystem looking for directory having inode=256
2) when the user mounts a subvolume as root, he has not direct access to all subvolume unless he also mount / (rootid=5) on another place. "btrfs sub list" has not this limit
BTW, my preferred choice is:
- mount a subvolume as root;
- mount the root filesystem (rootid=5) under /var/btrfs
- make snapshot and/or subvolume only under / (rootid=5), handle these in /var/btrfs
- if needed, mount a subvolume in the filesystem through fstab;
- however I am still searching a way to handle the snapshots which fully satisfy me (putting them under /, is not the best)
BR
--
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: What means "top level" in "btrfs subvolume list" ?
2017-09-30 11:57 What means "top level" in "btrfs subvolume list" ? Goffredo Baroncelli
2017-09-30 14:53 ` Peter Grandi
@ 2017-10-01 7:49 ` Andrei Borzenkov
1 sibling, 0 replies; 5+ messages in thread
From: Andrei Borzenkov @ 2017-10-01 7:49 UTC (permalink / raw)
To: kreijack, linux-btrfs
30.09.2017 14:57, Goffredo Baroncelli пишет:
> (please ignore my previous email, because I wrote somewhere "top id" instead of "top level")
> Hi All,
>
> I am trying to figure out which means "top level" in the output of "btrfs sub list"
>
>
Digging in git history - "top level" originally meant "subvolume where
path starts". Apparently original code allowed for "detached" roots not
present in tree of roots (deleted subvolume?)
> ghigo@venice:~$ sudo btrfs sub list /
> [sudo] password for ghigo:
> ID 257 gen 548185 top level 5 path debian
> ID 289 gen 418851 top level 257 path var/lib/machine> ID 299 gen 537230 top level 5 path boot
> ID 532 gen 502364 top level 257 path tmp/test1
> ID 533 gen 502277 top level 532 path tmp/test1/test2
> ID 534 gen 502407 top level 257 path tmp/test1.snap
> ID 535 gen 502363 top level 532 path tmp/test1/test3
> ID 536 gen 502407 top level 257 path tmp/test1.snap2
> ID 537 gen 537132 top level 5 path test
> ID 538 gen 537130 top level 537 path test/sub1
>
> The root filesystem is mounted as
>
> mount -o subvol=debian ....
>
>
> I think that "btrfs sub list" is buggy, and it outputs a "top level ID" equal to the "parent ID" (on the basis of the code).
Yes, apparently this was (unintentionally?) changed by commit
4f5ebb3ef55396ef976d3245e2cdf9860680df74 which also apparently changed
semantic of -o option - before this commit resolve_root() would produce
subvolume path relative to given top_id; after this commit path is
always relative to filesystem root.
Moreover, this fix by itself is buggy. It sets "top level" to immediate
parent, but option -o will setup filter by top_id, which means that only
immediate subvolumes be listed. To illustrate:
bor@10:~> /usr/sbin/btrfs sub cre tsub
Create subvolume './tsub'
bor@10:~> /usr/sbin/btrfs sub cre tsub/sub1
Create subvolume 'tsub/sub1'
bor@10:~> /usr/sbin/btrfs sub cre tsub/sub2
Create subvolume 'tsub/sub2'
bor@10:~> sudo btrfs sub li -p -o tsub
ID 346 gen 1960 parent 345 top level 345 path @/home/bor/tsub/sub1
ID 347 gen 1961 parent 345 top level 345 path @/home/bor/tsub/sub2
bor@10:~> /usr/sbin/btrfs sub cre tsub/sub1/subsub1
Create subvolume 'tsub/sub1/subsub1'
bor@10:~> /usr/sbin/btrfs sub cre tsub/sub2/subsub2
Create subvolume 'tsub/sub2/subsub2'
bor@10:~> sudo btrfs sub li -p -o tsub
ID 346 gen 1965 parent 345 top level 345 path @/home/bor/tsub/sub1
ID 347 gen 1966 parent 345 top level 345 path @/home/bor/tsub/sub2
it misses nested subvolumes.
> But I am still asking which would be the RIGHT "top level id". My Hypothesis, it should be the ID of the root subvolume ( or 5 if it is not mounted).
To remind - "top level" was intended as "subvolume to which shown path
is relative".
Given that the code now will fail (return -ENOENT) for detached root,
the only possible output can be 5. Except the controversial case of
"-o". Going back to original behavior is probably going to break some
scripts now.
But again, at this point we may have scripts that rely on current "top
level" semantic. The change was there for how much ... 3 and half years.
But documenting it in manual page would be good.
> So the output should be
>
>
> ghigo@venice:~$ sudo btrfs sub list /
> [sudo] password for ghigo:
> ID 257 gen 548185 top level 5 path debian
> ID 289 gen 418851 top level 257 path var/lib/machines
> ID 299 gen 537230 top level 5 path boot
> ID 532 gen 502364 top level 257 path tmp/test1
> ID 533 gen 502277 top level 257 path tmp/test1/test2
> ID 534 gen 502407 top level 257 path tmp/test1.snap
> ID 535 gen 502363 top level 257 path tmp/test1/test3
> ID 536 gen 502407 top level 257 path tmp/test1.snap2
> ID 537 gen 537132 top level 5 path test
> ID 538 gen 537130 top level 5 path test/sub1
>
>
> The subvolumes in the file system (mounted from /debian) are
>
> / ID = 5
> /debian ID = 257
> /debian/var/lib/machines ID = 289
> /boot ID = 299
> /debian/tmp/test1 ID = 532
> /debian/tmp/test1/test2 ID = 533
> /debian/tmp/test1.snap ID = 534
> /debian/tmp/test1/test3 ID = 535
> /debian/tmp/test1.snap2 ID = 536
> /test ID = 537
> /test/sub1 ID = 538
>
> BR
> G.Baroncelli
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-10-02 19:07 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-09-30 11:57 What means "top level" in "btrfs subvolume list" ? Goffredo Baroncelli
2017-09-30 14:53 ` Peter Grandi
2017-09-30 16:38 ` Andrei Borzenkov
2017-10-02 19:07 ` Goffredo Baroncelli
2017-10-01 7:49 ` Andrei Borzenkov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).