strange btrfs sub list output

I get a btrfs sub list output that I don't understand:

# btrfs sub list /backup/
ID 257 top level 5 path u1/linux/lvm+btrfs/storage/data/data
ID 260 top level 5 path u2/linux/lvm/linux/var/data
ID 262 top level 5 path u1/linux/lvm+btrfs/storage/data/snapshots/2010-10-11
ID 263 top level 5 path u2/linux/lvm/linux/home/snapshots/2011-04-07
ID 264 top level 5 path u2/linux/lvm/linux/root/snapshots/2011-04-07
ID 265 top level 5 path u2/linux/lvm/linux/var/snapshots/2011-04-07
ID 266 top level 5 path u1/linux/lvm+btrfs/storage/data/snapshots/2010-10-26
ID 267 top level 5 path u1/linux/lvm+btrfs/storage/data/snapshots/2010-11-08
ID 268 top level 5 path u1/linux/lvm+btrfs/storage/data/snapshots/2010-11-22
ID 269 top level 5 path u1/linux/lvm+btrfs/storage/data/snapshots/2010-12-15
ID 270 top level 5 path u2/linux/lvm/linux/home/snapshots/2011-04-14
ID 271 top level 5 path u2/linux/lvm/linux/root/snapshots/2011-04-14
ID 272 top level 5 path u2/linux/lvm/linux/var/snapshots/2011-04-14
ID 273 top level 5 path u1/linux/lvm+btrfs/storage/data/snapshots/2010-12-29
ID 274 top level 5 path u1/linux/lvm+btrfs/storage/data/snapshots/2011-01-26
ID 275 top level 5 path u1/linux/lvm+btrfs/storage/data/snapshots/2011-03-07
ID 276 top level 5 path u1/linux/lvm+btrfs/storage/data/snapshots/2011-04-01
ID 277 top level 5 path u2/linux/lvm/linux/home/data
ID 278 top level 5 path u2/linux/lvm/linux/home/snapshots/2011-04-27
ID 279 top level 5 path u2/linux/lvm/linux/root/snapshots/2011-04-27
ID 280 top level 5 path u2/linux/lvm/linux/var/snapshots/2011-04-27
ID 281 top level 5 path u3:10022/vm+xfs@u9/xvda1/g1/v4/data
ID 282 top level 5 path u3:10022/vm+xfs@u9/xvda1/g1/v4/snapshots/2011-05-19
ID 283 top level 5 path u5/vm+xfs@u9/xvda1/g1/v5/data
ID 284 top level 5 path u6:10022/vm+xfs@u8/xvda1/g8/v3/data
ID 286 top level 5 path u5/vm+xfs@u9/xvda1/g1/v5/snapshots/2011-05-24
ID 287 top level 285 path data
ID 288 top level 5 path u4/vm+xfs@u9/xvda1/g1/v1/data
ID 289 top level 5 path u4/vm+xfs@u9/xvda1/g1/v1/snapshots/2011-03-11
ID 290 top level 5 path u4/vm+xfs@u9/xvda1/g1/v2/data
ID 291 top level 5 path u4/vm+xfs@u9/xvda1/g1/v2/snapshots/2011-05-11
ID 292 top level 5 path u4/vm+xfs@u9/xvda1/g1/v1/snapshots/2011-05-11

There is no "/backup/data" directory. There is however a /backup/u6:10022/vm+xfs@u8/xvda1/g8/v3/snapshots/2011-03-30 that contains the same thing as what I get if I mount the fs with subvolid=287. And I did do a btrfs sub snap data snapshots/2011-03/30 there.

What could be the cause of that? How to fix it?

In case that matters, there used to be more components in the path of u6:10022/vm+xfs@u8/xvda1/g8/v3/data.

2011-05-26 22:22:03 +0100, Stephane Chazelas: [...]

Quoted 41 lines

I get a btrfs sub list output that I don't understand:

# btrfs sub list /backup/ ID 257 top level 5 path
u1/linux/lvm+btrfs/storage/data/data ID 260 top level 5 path
u2/linux/lvm/linux/var/data ID 262 top level 5 path
u1/linux/lvm+btrfs/storage/data/snapshots/2010-10-11 ID 263 top
level 5 path u2/linux/lvm/linux/home/snapshots/2011-04-07 ID 264
top level 5 path u2/linux/lvm/linux/root/snapshots/2011-04-07 ID
265 top level 5 path u2/linux/lvm/linux/var/snapshots/2011-04-07
ID 266 top level 5 path
u1/linux/lvm+btrfs/storage/data/snapshots/2010-10-26 ID 267 top
level 5 path u1/linux/lvm+btrfs/storage/data/snapshots/2010-11-08
ID 268 top level 5 path
u1/linux/lvm+btrfs/storage/data/snapshots/2010-11-22 ID 269 top
level 5 path u1/linux/lvm+btrfs/storage/data/snapshots/2010-12-15
ID 270 top level 5 path
u2/linux/lvm/linux/home/snapshots/2011-04-14 ID 271 top level 5
path u2/linux/lvm/linux/root/snapshots/2011-04-14 ID 272 top
level 5 path u2/linux/lvm/linux/var/snapshots/2011-04-14 ID 273
top level 5 path
u1/linux/lvm+btrfs/storage/data/snapshots/2010-12-29 ID 274 top
level 5 path u1/linux/lvm+btrfs/storage/data/snapshots/2011-01-26
ID 275 top level 5 path
u1/linux/lvm+btrfs/storage/data/snapshots/2011-03-07 ID 276 top
level 5 path u1/linux/lvm+btrfs/storage/data/snapshots/2011-04-01
ID 277 top level 5 path u2/linux/lvm/linux/home/data ID 278 top
level 5 path u2/linux/lvm/linux/home/snapshots/2011-04-27 ID 279
top level 5 path u2/linux/lvm/linux/root/snapshots/2011-04-27 ID
280 top level 5 path u2/linux/lvm/linux/var/snapshots/2011-04-27
ID 281 top level 5 path u3:10022/vm+xfs@u9/xvda1/g1/v4/data ID
282 top level 5 path
u3:10022/vm+xfs@u9/xvda1/g1/v4/snapshots/2011-05-19 ID 283 top
level 5 path u5/vm+xfs@u9/xvda1/g1/v5/data ID 284 top level 5
path u6:10022/vm+xfs@u8/xvda1/g8/v3/data ID 286 top level 5 path
u5/vm+xfs@u9/xvda1/g1/v5/snapshots/2011-05-24 ID 287 top level
285 path data ID 288 top level 5 path
u4/vm+xfs@u9/xvda1/g1/v1/data ID 289 top level 5 path
u4/vm+xfs@u9/xvda1/g1/v1/snapshots/2011-03-11 ID 290 top level 5
path u4/vm+xfs@u9/xvda1/g1/v2/data ID 291 top level 5 path
u4/vm+xfs@u9/xvda1/g1/v2/snapshots/2011-05-11 ID 292 top level 5
path u4/vm+xfs@u9/xvda1/g1/v1/snapshots/2011-05-11

[...]

Quoted 10 lines

There is no "/backup/data" directory. There is however a /backup/u6:10022/vm+xfs@u8/xvda1/g8/v3/snapshots/2011-03-30 that contains the same thing as what I get if I mount the fs with subvolid=287. And I did do a btrfs sub snap data snapshots/2011-03/30 there.

What could be the cause of that? How to fix it?

In case that matters, there used to be more components in the path of u6:10022/vm+xfs@u8/xvda1/g8/v3/data.

[...]

I tried deleting the /backup/u6:10022/vm+xfs@u8/xvda1/g8/v3/snapshots/2011-03-30 subvolume (what seems to be id 287) and I get:

# btrfs sub delete snapshots/2011-03-30 Delete subvolume
'/backup/u6:10022/vm+xfs@u8/xvda1/g8/v3/snapshots/2011-03-30'
ERROR: cannot delete
'/backup/u6:10022/vm+xfs@u8/xvda1/g8/v3/snapshots/2011-03-30'

With a strace, it tells me:

ioctl(3, 0x5000940f, 0x7fffc7841a80) = -1 ENOTEMPTY (Directory not empty)

Then I realised that there was a "data" directory in there and that snapshots/2011-03-30 was actually id 285 (which doesn't appear in the btrfs sub list) and "snapshots/2011-03-30/data" is id 287.

What do those top-level IDs mean by the way?

Then I was able to delete snapshots/2011-03-30/data, but snapshots/2011-03-30 still didn't appear in the list.

Then I was able to delete snapshots/2011-03-30 and recreate it, and this time it was fine.

Still don't know what happened there.

Quoted 1 line

What do those top-level IDs mean by the way?

The top-level ID associated with a subvolume is NOT the ID of this particular subvolume but of the subvolume containing it. Since the "root/initial" (sub-)volume has always ID 0, the subvolumes of "depth" 1 will all have top-level ID set to 0. You need those top-level IDs to correctly mount a specific subvolume by name.

# mount /dev/dummy -o subvol=<subvolume>,subvolrootid=<top-level ID>
/mountpoint

Of course, you do need them, if you specify the subvolume to mount by its ID.

2011-05-27 10:21:03 +0200, Andreas Philipp:

[...]

Quoted 7 lines

Quoted 1 line

What do those top-level IDs mean by the way?

The top-level ID associated with a subvolume is NOT the ID of this particular subvolume but of the subvolume containing it. Since the "root/initial" (sub-)volume has always ID 0, the subvolumes of "depth" 1 will all have top-level ID set to 0. You need those top-level IDs to correctly mount a specific subvolume by name.

Quoted 5 lines

# mount /dev/dummy -o subvol=<subvolume>,subvolrootid=<top-level ID>
/mountpoint

Of course, you do need them, if you specify the subvolume to mount by its ID.

[...]

Thanks Andreas for pointing that subvolrootid (might be worth adding it to
https://btrfs.wiki.kernel.org/index.php/Getting_started#Mount_Options
BTW).

In my case, on a freshly made btrfs file system, subvolumes have top-level 5. (and neither volume with id 0 or 5 appear in the btrfs sub list).

All the top-levels are 5, and I don't even know how to create a subvolume with a different top-level there, so I wonder how that subvol that I had created with

Quoted 21 lines · Stephane Chazelas

2011-05-27 10:21:03 +0200, Andreas Philipp:

[...]

Quoted 7 lines

Quoted 1 line

What do those top-level IDs mean by the way?

The top-level ID associated with a subvolume is NOT the ID of this particular subvolume but of the subvolume containing it. Since the "root/initial" (sub-)volume has always ID 0, the subvolumes of "depth" 1 will all have top-level ID set to 0. You need those top-level IDs to correctly mount a specific subvolume by name.

Quoted 5 lines

# mount /dev/dummy -o subvol=<subvolume>,subvolrootid=<top-level ID>
/mountpoint

Of course, you do need them, if you specify the subvolume to mount by its ID.

[...]

Thanks Andreas for pointing that subvolrootid (might be worth adding it to
https://btrfs.wiki.kernel.org/index.php/Getting_started#Mount_Options
BTW).

Quoted 7 lines

In my case, on a freshly made btrfs file system, subvolumes have top-level 5. (and neither volume with id 0 or 5 appear in the btrfs sub list).

All the top-levels are 5, and I don't even know how to create a subvolume with a different top-level there, so I wonder how that subvol that I had created with

Actually, top-level subvolume ID=0 is a fiction. Internally, each subvolume is a separate FS tree (an FS tree in btrfs is a btree containing all of the inode and directory information for some subvolume). These trees are all referred to by a tree called the "root tree", which indexes all of the btrees in the filesystem.

The root tree has a unique reference ID for each tree that it points to: most of the trees (extent tree, device tree, etc) have fixed and well-known IDs smaller than 256. The FS tree for the top-level subvolume -- the one that doesn't show up on a subvolume list -- always has ID 5. Hence the containing subvolume for most of your subvolumes is 5. The FS trees for the non-top-level subvolumes have IDs starting at 256 and increasing monotonically.

Internally, there's a bit of a fiddle in the API, where a request for a subvolume ID of 0 is (sometimes) translated to an ID of 5. It's not always done, I think, and those cases where a subvol ID of 0 doesn't get you the top-level subvolume should be treated as bugs.

That's all rather dense, and probably too much information. Hope it's helpful, though.

Hugo.

That's all rather dense, and probably too much information. Hope
it's helpful, though.

2011-05-27 10:12:24 +0100, Hugo Mills:

[skipped useful clarification]

Quoted 3 lines

That's all rather dense, and probably too much information. Hope
it's helpful, though.

[...]

It is, thanks.

How would one end up in a situation where the output of "btrfs sub list ." has:

ID 287 top level 285 path data

How could a "subvolume 285" become a "top level"?

How does one get a subvolume with a top-level other than "5"?

Quoted 9 lines · Stephane Chazelas

2011-05-27 10:12:24 +0100, Hugo Mills:

[skipped useful clarification]

Quoted 3 lines

That's all rather dense, and probably too much information. Hope it's helpful, though.

[...]

It is, thanks.

Quoted 8 lines

How would one end up in a situation where the output of "btrfs sub list ." has:

ID 287 top level 285 path data

How could a "subvolume 285" become a "top level"?

How does one get a subvolume with a top-level other than "5"?

This just means that subvolume 287 was created (somewhere) inside subvolume 285.

Due to the way that the FS trees and subvolumes work, there's no global namespace structure in btrfs; that is, there's no single data structure that represents the entirety of the file/directory hierarchy in the filesystem. Instead, it's broken up into these sub-namespaces called subvolumes, and we only record parent/child relationships for each subvolume separately. The "full path" you get from "btrfs subv list" is reconstructed from that information in userspace(*).

Hugo.

(*) Here's how it does it:

The userspace tool gets a list of every subvolume by looking at the FS tree. It uses the corresponding back-refs to get the inode that represents each of those FS trees inside its parent:

Subvol inode in subvol
256 991 5
257 896 256
258 1073 257

From the inode numbers, it can then recursively walk back up the directory path to the top of each subvolume:

Subvol inode in subvol relative path
256 991 5 henry
257 896 256 edward/mary
258 1073 257 elizabeth

From that, it can then reconstruct the full pathnames, by walking back up the subvolume tree:

subvol 258 is elizabeth in 257
is edward/mary/elizabeth in 256
is henry/edward/mary/elizabeth in 5

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

Quoted 51 lines · Hugo Mills

Quoted 9 lines · Stephane Chazelas

2011-05-27 10:12:24 +0100, Hugo Mills:

[skipped useful clarification]

Quoted 3 lines

That's all rather dense, and probably too much information. Hope it's helpful, though.

[...]

It is, thanks.

Quoted 8 lines

How would one end up in a situation where the output of "btrfs sub list ." has:

ID 287 top level 285 path data

How could a "subvolume 285" become a "top level"?

How does one get a subvolume with a top-level other than "5"?

This just means that subvolume 287 was created (somewhere) inside subvolume 285.

Due to the way that the FS trees and subvolumes work, there's no global namespace structure in btrfs; that is, there's no single data structure that represents the entirety of the file/directory hierarchy in the filesystem. Instead, it's broken up into these sub-namespaces called subvolumes, and we only record parent/child relationships for each subvolume separately. The "full path" you get from "btrfs subv list" is reconstructed from that information in userspace(*).

Hugo.

(*) Here's how it does it:

The userspace tool gets a list of every subvolume by looking at the FS tree. It uses the corresponding back-refs to get the inode that represents each of those FS trees inside its parent:

Subvol inode in subvol
256 991 5
257 896 256
258 1073 257

From the inode numbers, it can then recursively walk back up the directory path to the top of each subvolume:

Subvol inode in subvol relative path
256 991 5 henry
257 896 256 edward/mary
258 1073 257 elizabeth

Quoted 6 lines

From that, it can then reconstruct the full pathnames, by walking back up the subvolume tree:

subvol 258 is elizabeth in 257
is edward/mary/elizabeth in 256
is henry/edward/mary/elizabeth in 5

Just one (hopefully) short question: A line in the ouput of btrfs subvolume list like
ID 257 top level 5 path test1/test1.1
says that the subvolume with name test1.1 (the last segment of the path) and ID 257 has the path test1/test1.1 starting at the top level subvolume which has ID 5 ?

Quoted 3 lines

How could a "subvolume 285" become a "top level"?

How does one get a subvolume with a top-level other than "5"?

This just means that subvolume 287 was created (somewhere) inside
subvolume 285.

Due to the way that the FS trees and subvolumes work, there's no
global namespace structure in btrfs; that is, there's no single data structure that represents the entirety of the file/directory hierarchy in the filesystem. Instead, it's broken up into these sub-namespaces called subvolumes, and we only record parent/child relationships for each subvolume separately. The "full path" you get from "btrfs subv list" is reconstructed from that information in userspace(*).

2011-05-27 10:45:23 +0100, Hugo Mills:

[...]

Quoted 7 lines

Quoted 3 lines

How could a "subvolume 285" become a "top level"?

How does one get a subvolume with a top-level other than "5"?

This just means that subvolume 287 was created (somewhere) inside
subvolume 285.

Quoted 7 lines

Due to the way that the FS trees and subvolumes work, there's no
global namespace structure in btrfs; that is, there's no single data structure that represents the entirety of the file/directory hierarchy in the filesystem. Instead, it's broken up into these sub-namespaces called subvolumes, and we only record parent/child relationships for each subvolume separately. The "full path" you get from "btrfs subv list" is reconstructed from that information in userspace(*).

[...]

Thanks, I can understand that. What I don't get is how one creates a subvol with a top-level other than 5. I might be missing the obvious, though.

If I do:

btrfs sub create A
btrfs sub create A/B
btrfs sub snap A A/B/C

A, A/B, A/B/C have their top-level being 5. How would I get a new snapshot to be a child of A/B for instance?

In my case, 285, was not appearing in the btrfs sub list output, 287 was a child of 285 with path "data" while all I did was create a snapshot of 284 (path u6:10022/vm+xfs@u8/xvda1/g8/v3/data in vol 5) in u6:10022/vm+xfs@u8/xvda1/g8/v3/snapshots/2011-03-30

So I did manage to get a volume with a parent other than 5, but I did not ask for it.

2011-05-27 10:45:23 +0100, Hugo Mills: [...]

Quoted 7 lines

Quoted 3 lines

How could a "subvolume 285" become a "top level"?

How does one get a subvolume with a top-level other than "5"?

This just means that subvolume 287 was created (somewhere) inside subvolume 285.

Quoted 8 lines

Due to the way that the FS trees and subvolumes work, there's no global namespace structure in btrfs; that is, there's no single data structure that represents the entirety of the file/directory hierarchy in the filesystem. Instead, it's broken up into these sub-namespaces called subvolumes, and we only record parent/child relationships for each subvolume separately. The "full path" you get from "btrfs subv list" is reconstructed from that information in userspace(*).

[...]

Thanks, I can understand that. What I don't get is how one creates a subvol with a top-level other than 5. I might be missing the obvious, though.

If I do:

btrfs sub create A btrfs sub create A/B btrfs sub snap A A/B/C

A, A/B, A/B/C have their top-level being 5. How would I get a new snapshot to be a child of A/B for instance?

In my case, 285, was not appearing in the btrfs sub list output, 287 was a child of 285 with path "data" while all I did was create a snapshot of 284 (path u6:10022/vm+xfs@u8/xvda1/g8/v3/data in vol
5) in u6:10022/vm+xfs@u8/xvda1/g8/v3/snapshots/2011-03-30

So I did manage to get a volume with a parent other than 5, but I did not ask for it.

Quoted 18 lines

Thanks, I can understand that. What I don't get is how one creates a subvol with a top-level other than 5. I might be missing the obvious, though.

If I do:

btrfs sub create A btrfs sub create A/B btrfs sub snap A A/B/C

A, A/B, A/B/C have their top-level being 5. How would I get a new snapshot to be a child of A/B for instance?

In my case, 285, was not appearing in the btrfs sub list output, 287 was a child of 285 with path "data" while all I did was create a snapshot of 284 (path u6:10022/vm+xfs@u8/xvda1/g8/v3/data in vol
5) in u6:10022/vm+xfs@u8/xvda1/g8/v3/snapshots/2011-03-30

So I did manage to get a volume with a parent other than 5, but I did not ask for it.

Reconsidering the explanations on btrfs subvolume list in this thread I get the impression that a line in the output of btrfs subvolume list with top level other than 5 indicates that the backrefs from one subvolume to its parent are broken.

What's your opinion on this?

2011-05-27 13:49:52 +0200, Andreas Philipp:

[...]

Quoted 18 lines

Quoted 18 lines

Thanks, I can understand that. What I don't get is how one creates a subvol with a top-level other than 5. I might be missing the obvious, though.

If I do:

btrfs sub create A btrfs sub create A/B btrfs sub snap A A/B/C

A, A/B, A/B/C have their top-level being 5. How would I get a new snapshot to be a child of A/B for instance?

In my case, 285, was not appearing in the btrfs sub list output, 287 was a child of 285 with path "data" while all I did was create a snapshot of 284 (path u6:10022/vm+xfs@u8/xvda1/g8/v3/data in vol
5) in u6:10022/vm+xfs@u8/xvda1/g8/v3/snapshots/2011-03-30

So I did manage to get a volume with a parent other than 5, but I did not ask for it.

[...]

Quoted 6 lines

Reconsidering the explanations on btrfs subvolume list in this thread I get the impression that a line in the output of btrfs subvolume list with top level other than 5 indicates that the backrefs from one subvolume to its parent are broken.

What's your opinion on this?

[...]

Given that I don't really get what the parent-child relationship means in that context, I can't really comment.

In effect, the snapshot had been created and was attached to the right directory (but didn't appear in the sub list), and there was an additional "data" volume that I had not asked for nor created that had the snapshot above as parent and that did appear in the sub list.

It pretty much looks like a bug to me, I'd like to understand more so that I can maybe try and avoid running into it again.

Quoted 33 lines · Stephane Chazelas

2011-05-27 13:49:52 +0200, Andreas Philipp: [...]

Quoted 20 lines

Quoted 20 lines

Thanks, I can understand that. What I don't get is how one creates a subvol with a top-level other than 5. I might be missing the obvious, though.

If I do:

btrfs sub create A btrfs sub create A/B btrfs sub snap A A/B/C

A, A/B, A/B/C have their top-level being 5. How would I get a new snapshot to be a child of A/B for instance?

In my case, 285, was not appearing in the btrfs sub list output, 287 was a child of 285 with path "data" while all I did was create a snapshot of 284 (path u6:10022/vm+xfs@u8/xvda1/g8/v3/data in vol 5) in u6:10022/vm+xfs@u8/xvda1/g8/v3/snapshots/2011-03-30

So I did manage to get a volume with a parent other than 5, but I did not ask for it.

[...]

Quoted 6 lines

Reconsidering the explanations on btrfs subvolume list in this thread I get the impression that a line in the output of btrfs subvolume list with top level other than 5 indicates that the backrefs from one subvolume to its parent are broken.

What's your opinion on this?

[...]

Given that I don't really get what the parent-child relationship means in that context, I can't really comment.

Quoted 8 lines

In effect, the snapshot had been created and was attached to the right directory (but didn't appear in the sub list), and there was an additional "data" volume that I had not asked for nor created that had the snapshot above as parent and that did appear in the sub list.

It pretty much looks like a bug to me, I'd like to understand more so that I can maybe try and avoid running into it again.

i'm actually really interested in the conclusion to this thread because i _want_ to create subvols with a new parent ... i didn't realize this wasn't possible (nor the mount option) until reading this thread. this would give me a little more flexibility with initcpio hooks and the like vs. packing the btrfs root with tons of hidden files [subvols] or using IDs directly ...

i tried absolutely everything i could think of to reproduce this but all subvols ended up having a top level id of 5.

... so, is there any known way to _purposefully_ create parented subvols with the current tools?

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

Quoted 51 lines · C Anthony Risinger

Quoted 33 lines · Stephane Chazelas

2011-05-27 13:49:52 +0200, Andreas Philipp: [...]

Quoted 20 lines

Quoted 20 lines

Thanks, I can understand that. What I don't get is how one creates a subvol with a top-level other than 5. I might be missing the obvious, though.

If I do:

btrfs sub create A btrfs sub create A/B btrfs sub snap A A/B/C

A, A/B, A/B/C have their top-level being 5. How would I get a new snapshot to be a child of A/B for instance?

In my case, 285, was not appearing in the btrfs sub list output, 287 was a child of 285 with path "data" while all I did was create a snapshot of 284 (path u6:10022/vm+xfs@u8/xvda1/g8/v3/data in vol 5) in u6:10022/vm+xfs@u8/xvda1/g8/v3/snapshots/2011-03-30

So I did manage to get a volume with a parent other than 5, but I did not ask for it.

[...]

Quoted 6 lines

Reconsidering the explanations on btrfs subvolume list in this thread I get the impression that a line in the output of btrfs subvolume list with top level other than 5 indicates that the backrefs from one subvolume to its parent are broken.

What's your opinion on this?

[...]

Given that I don't really get what the parent-child relationship means in that context, I can't really comment.

Quoted 8 lines

In effect, the snapshot had been created and was attached to the right directory (but didn't appear in the sub list), and there was an additional "data" volume that I had not asked for nor created that had the snapshot above as parent and that did appear in the sub list.

It pretty much looks like a bug to me, I'd like to understand more so that I can maybe try and avoid running into it again.

i'm actually really interested in the conclusion to this thread because i _want_ to create subvols with a new parent ... i didn't realize this wasn't possible (nor the mount option) until reading this thread. this would give me a little more flexibility with initcpio hooks and the like vs. packing the btrfs root with tons of hidden files [subvols] or using IDs directly ...

Quoted 5 lines

i tried absolutely everything i could think of to reproduce this but all subvols ended up having a top level id of 5.

... so, is there any known way to _purposefully_ create parented subvols with the current tools?

Hopefully, I can help clarify this a little bit. In fact, this is the 'usual' case. With the attached patch to the master branch of btrfs-progs-unstable you can 'watch' how the btrfs subvolume list command builds the full path of the listed subvolumes. Additionally, it gives you the IDs of the parent subvolumes. See the following example.

ID 256 top level 5 path test1
ID 257 top level 256 path test1.1
ID 257 top level 5 path test1/test1.1
ID 258 top level 5 path test2
ID 259 top level 258 path test2.1
ID 259 top level 5 path test2/test2.1

- From the second line you see that subvolume ID 256 really is ID 257's parent. Additionally, only test1 and test2 have parent ID 5 or in your terminology are in the btrfs root.

Quoted 56 lines · Andreas Philipp

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

Quoted 51 lines · C Anthony Risinger

Quoted 33 lines · Stephane Chazelas

2011-05-27 13:49:52 +0200, Andreas Philipp: [...]

Quoted 20 lines

Quoted 20 lines

Thanks, I can understand that. What I don't get is how one creates a subvol with a top-level other than 5. I might be missing the obvious, though.

If I do:

btrfs sub create A btrfs sub create A/B btrfs sub snap A A/B/C

A, A/B, A/B/C have their top-level being 5. How would I get a new snapshot to be a child of A/B for instance?

In my case, 285, was not appearing in the btrfs sub list output, 287 was a child of 285 with path "data" while all I did was create a snapshot of 284 (path u6:10022/vm+xfs@u8/xvda1/g8/v3/data in vol 5) in u6:10022/vm+xfs@u8/xvda1/g8/v3/snapshots/2011-03-30

So I did manage to get a volume with a parent other than 5, but I did not ask for it.

[...]

Quoted 6 lines

Reconsidering the explanations on btrfs subvolume list in this thread I get the impression that a line in the output of btrfs subvolume list with top level other than 5 indicates that the backrefs from one subvolume to its parent are broken.

What's your opinion on this?

[...]

Given that I don't really get what the parent-child relationship means in that context, I can't really comment.

Quoted 8 lines

In effect, the snapshot had been created and was attached to the right directory (but didn't appear in the sub list), and there was an additional "data" volume that I had not asked for nor created that had the snapshot above as parent and that did appear in the sub list.

It pretty much looks like a bug to me, I'd like to understand more so that I can maybe try and avoid running into it again.

i'm actually really interested in the conclusion to this thread because i _want_ to create subvols with a new parent ... i didn't realize this wasn't possible (nor the mount option) until reading this thread. this would give me a little more flexibility with initcpio hooks and the like vs. packing the btrfs root with tons of hidden files [subvols] or using IDs directly ...

Quoted 7 lines

Quoted 5 lines

i tried absolutely everything i could think of to reproduce this but all subvols ended up having a top level id of 5.

... so, is there any known way to _purposefully_ create parented subvols with the current tools?

Hopefully, I can help clarify this a little bit. In fact, this is th=

Quoted 4 lines

'usual' case. With the attached patch to the master branch of btrfs-progs-unstable you can 'watch' how the btrfs subvolume list command builds the full path of the listed subvolumes. Additionally, it gives you the IDs of the parent subvolumes. See the following exa=

Quoted 9 lines

ID 256 top level 5 path test1
ID 257 top level 256 path test1.1
ID 257 top level 5 path test1/test1.1
ID 258 top level 5 path test2
ID 259 top level 258 path test2.1
ID 259 top level 5 path test2/test2.1

- From the second line you see that subvolume ID 256 really is ID 25=

Quoted 1 line

parent. Additionally, only test1 and test2 have parent ID 5 or in yo=

Quoted 1 line

terminology are in the btrfs root.

aaah, ok ... this is what i thought was happening too after taking a peek at the sources (albeit i don't write any C) and seems to match what Hugo was saying if i understand him correctly.

this also makes sense what you said about a broken link ... since normally the btrfs tool will not let you remove a subvol that has other subvols nested within it ... though *technically* it does not seem to matter, yes? =C2=A0must have been a fluke/bug in the btrfs =

where a higher level subvol was removed before it's child somehow, is this correct? =C2=A0or is the FS itself slightly broken when this hap=

yeah i know that's kind of "my terminology" :-) ... i've spent a lot of time explaining btrfs concepts to others and that term always seemed to makes the most sense to people ... top-level can change, default can change, etc, etc ... but the btrfs root can only mean one thing -- the most "bottomest" of the bottom (or top, if you prefe=

:-)

i'll try this out later tonight, thanks.