From: Axel Burri <axel@tty0.ch>
To: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: btrfs-progs: bugs in "subvolume list" command
Date: Sat, 3 Oct 2015 14:29:41 +0200 [thread overview]
Message-ID: <560FCA35.7010100@tty0.ch> (raw)
While digging deeper into the "subvolume list" command, I found
some flaws which I'm addressing here:
1. The "parent id" seems to be a relict of old days.
btrfs-subvolume(8) states:
"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."
The "Mount Options" site [1] tells me that the "subvolrootid="
mount option is deprecated since kernel 3.2. A quick check on my
system (kernel 4.2.2) shows that "parent" is equal to "top level"
for all subvolumes. Is this always true for kernels >3.2 ?
Furthermore, the output is confusing, as "parent" is not related
at all to "parent_uuid".
Note that this is also true for "subvolume show", which
prints "parent" as "Parent ID".
Suggestion: drop the '-p' option and don't print "parent"
anymore. I don't know the "backwards compatibility policy" the
btrfs-devs have here, but my impression is that kernel 3.2 is not
really supported anymore.
2. The output of -a option (as well as -o) is inconsistent. Given
/tmp/btr_test is mounted with subvolid=0:
# btrfs subvolume create /tmp/btr_test/vol0
# btrfs subvolume create /tmp/btr_test/vol0/vol1
# btrfs subvolume create /tmp/btr_test/vol0/vol1/vol2
# list_path=/tmp/btr_test
# btrfs subvolume list -a $list_path
ID 256 gen 8 top level 5 path vol0
ID 257 gen 9 top level 256 path <FS_TREE>/vol0/vol1
ID 258 gen 9 top level 257 path <FS_TREE>/vol0/vol1/vol2
The only relative path shown is "vol0", which is
at "$list_path/vol0", as expected. But then "vol0/vol1" are
printed as absolute, while they are relative to $list_path.
# list_path=/tmp/btr_test/vol0
# btrfs subvolume list -a $list_path
ID 256 gen 8 top level 5 path <FS_TREE>/vol0
ID 257 gen 9 top level 256 path vol0/vol1
ID 258 gen 9 top level 257 path <FS_TREE>/vol0/vol1/vol2
But if $list_path points to a subvolume, the relative path shown
is now "vol0/vol1", which is actually at "$list_path/../vol0/vol1".
Things get even more confusing when subvolumes are within
directories:
# mkdir /tmp/btr_test/vol0/dir1
# btrfs subvolume create /tmp/btr_test/vol0/dir1/vol3
# list_path=/tmp/btr_test/vol0/dir1
# btrfs subvolume list -a $list_path
ID 256 gen 11 top level 5 path <FS_TREE>/vol0
ID 257 gen 9 top level 256 path vol0/vol1
ID 258 gen 9 top level 257 path <FS_TREE>/vol0/vol1/vol2
ID 259 gen 11 top level 256 path vol0/dir1/vol3
I know that handling "real" directories is very tricky to handle
correctly (involving symlinks et all), and is probably not a
feature that "subvolume list" command should handle.
Suggestions:
- Fix '-a' option to also print sub-subvolumes as relative, or
drop it (there is the -o option for this purpose).
- Fix output of '-o' option, by always printing relative
paths ("vol1" instead of "vol0/vol1" in the example above).
Regards,
- Axel
[1] https://btrfs.wiki.kernel.org/index.php/Mount_options
reply other threads:[~2015-10-03 12:29 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=560FCA35.7010100@tty0.ch \
--to=axel@tty0.ch \
--cc=linux-btrfs@vger.kernel.org \
/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.