strange btrfs sub list output

strange btrfs sub list output

[Stephane Chazelas]

Hiya,

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

See ID 287 above.

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.

Thanks,
Stephane

Re: strange btrfs sub list output

[Stephane Chazelas]

2011-05-26 22:22:03 +0100, Stephane Chazelas:
[...]
> 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.
[...]

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.

-- 
Stephane

Re: strange btrfs sub list output

[Andreas Philipp]

On 27.05.2011 10:01, Stephane Chazelas wrote:
> 2011-05-26 22:22:03 +0100, Stephane Chazelas: [...]
>> 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.
> [...]
>
> 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?
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.

Cheers,
Andreas Philipp

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

Re: strange btrfs sub list output

[Stephane Chazelas]

2011-05-27 10:21:03 +0200, Andreas Philipp:
[...]
> > 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.
[...]

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

btrfs sub snap data snapshots/2011-03-30

ending up being a subvolume with ID 285 that doesn't appear in
the "btrfs sub list" and contains a subvolume of "path" "data"
in there (with its top-level being 285). All the other
subvolumes and snapshots I've created in the exact same way are
created with a top-level 5 and have an entry in "btrfs sub list"
and don't have subvolumes of their own.

-- 
Stephane

Re: strange btrfs sub list output

[Stephane Chazelas]

Is there a way to derive the subvolume ID from the stat(2)
st_dev, by the way.

# btrfs sub list .
ID 256 top level 5 path a
ID 257 top level 5 path b
# zstat +dev . a b
. 27
a 28
b 29

Are the dev numbers allocated in the same order as the
subvolids? Would there be any /sys, /proc, ioctl interface to
get this kind of information?

-- 
Stephane

Re: strange btrfs sub list output

[Hugo Mills]

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

On Fri, May 27, 2011 at 09:47:33AM +0100, Stephane Chazelas wrote:
> 2011-05-27 10:21:03 +0200, Andreas Philipp:
> [...]
> > > 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.
> [...]
> 
> 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

   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.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
  --- A linked list is still a binary tree.  Just a very unbalanced ---  
                             one.  -- dragon                             

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: strange btrfs sub list output

[Andreas Philipp]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
On 27.05.2011 11:12, Hugo Mills wrote:
> On Fri, May 27, 2011 at 09:47:33AM +0100, Stephane Chazelas wrote:
>> 2011-05-27 10:21:03 +0200, Andreas Philipp:
>> [...]
>>>> 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.
>> [...]
>>
>> 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
>
> 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.
Thank you for all this information. Once I had a such a situation,
where mount with subvolid=0 did not mount the top-level subvolume. I
will try to recreate it with a recent kernel.

Thanks,
Andreas

>
> That's all rather dense, and probably too much information. Hope
> it's helpful, though.
>
> Hugo.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJN323eAAoJEJIcBJ3+XkgiFe8QALC9pa9DwygWNhULHF1jGoqY
+sHCvgD5WazkcquFD3xWg2pc52rnvDWpdeJAPw+6DzViCqnrk6lICyhhvjnAbm8a
h/87/7cV2CZbcVn/v283iuPLsok+HXsiyoMUHSEOhSCAE8CvveZbK7LtMSxagQpv
+e9TM9HUImw6UweYZ2LwMXY/Wu1z9yBaG/JuOq2MkslLniFekKaIPe8eZD4aej3o
RFkVKplvx3egu5lVJMDaK4rpL8xrQVxE4G8CtHLvVKRzJVHs8V3XTccaXmwpDks6
sZ+lzeU2+lNg+776K9+saXOuT9Ytuo0rpcDiEUAYxBO2DxSmbV2NArYkTLo0C3Sf
32+ecoqtZeNJH/v9a68+Pq0UH5cualLROGwyoc+MgqqIB+4zFq+nuTqk9eGtKchh
2YxQePXejnVsga8wgFMFSDYYaGKtfYUDKM+loq5XA/1A9bqjprIC40ovc3AHcJID
eqb861TEGXDBMajhFlLICk4YxyLd87ze6BOa4NxWwpVjkLW4HHPplsbW6EkTJBv6
bVwKDIpE4bmIpovIhRwxo5Eba4DNRtHrRD7U+2Ep+Juxx8n3y6DQD+qm40mOEtG0
oAhpVE/rKcR6FTxHPWon6lGH6D51bDDVOxVTwAyzETGbRA+eSA3nP05dtisXjEB2
07UBm2s0wHX7oQKOiATE
=R/Ih
-----END PGP SIGNATURE-----

Re: strange btrfs sub list output

[Stephane Chazelas]

2011-05-27 10:12:24 +0100, Hugo Mills:
[skipped useful clarification]
> 
>    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"?

-- 
Stephane

Re: strange btrfs sub list output

[Hugo Mills]

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

On Fri, May 27, 2011 at 10:30:29AM +0100, Stephane Chazelas wrote:
> 2011-05-27 10:12:24 +0100, Hugo Mills:
> [skipped useful clarification]
> > 
> >    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"?

   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

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
  --- A linked list is still a binary tree.  Just a very unbalanced ---  
                             one.  -- dragon                             

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: strange btrfs sub list output

[Andreas Philipp]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
On 27.05.2011 11:45, Hugo Mills wrote:
> On Fri, May 27, 2011 at 10:30:29AM +0100, Stephane Chazelas wrote:
>> 2011-05-27 10:12:24 +0100, Hugo Mills:
>> [skipped useful clarification]
>>>
>>> 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"?
>
> 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
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 ?

Thanks,
Andreas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJN33ezAAoJEJIcBJ3+Xkgi3egP/25y7JjnHJ9ZfQ2TF0cVWlhh
4FSHKhXlokH7E8fMcBbwP6YTB2zJioRkdWKmzoNjAvLlL8QkI7PvljAipe7YMgai
Zq+FNzN2y6qkpNBhdpJC0rnURbtD7neDdcRCDF3uatP2p+m6UghfPyTfqX31h1qc
UOp+3r+HLvlhAtKILxRaIZHidpS9ThZyN2mFHyKbyMMCoFYRXlJwL8xurPWdInbQ
sgjDmXVstsnoTcDaCsdWfUkRiLyPeiieOgCiB0X+/GdEG/gE6ICtzOf93fIeJu/B
CdGoaOSz73UIPdXstqiawhKxB83Ly68GNfoc/mrjFEml91KalGUnq/6f/344u6mB
2Ipwn1dpeC5ImwZO+VEc1HSv/GPCWyotUFzjV8NB/CcYYehX8GiNY0cSaT0NjTzs
ycUOOJUTWHTmavdT8ryDILPqSsqzMnN9NnrjJhs7EjEXSkvRxNQ4vUNOsWvCPjJl
HlooInMQ8/QTBkBLPkkiHWmhNuUaMPH6DJ85v6RNpFLiyf9TFDzBJvvyrZbkWx2y
tIvg8C1oKuZ1iulZidfY36h2wf4u/DuYgNYPSL0vsdOfABStn9MBeqPbqeF6fF42
AJ0gzVd+cqIWiFbnXEi4Zxt72l1DViLqe3Rxij2u00QOPRMtgGoKcwY7WmLKBnU5
1/vjmYvTJNnShewXMvsh
=zCSk
-----END PGP SIGNATURE-----

Re: strange btrfs sub list output

[Hugo Mills]

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

On Fri, May 27, 2011 at 12:06:44PM +0200, Andreas Philipp wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>  
> On 27.05.2011 11:45, Hugo Mills wrote:
> > On Fri, May 27, 2011 at 10:30:29AM +0100, Stephane Chazelas wrote:
> >> 2011-05-27 10:12:24 +0100, Hugo Mills:
> >> [skipped useful clarification]
> >>>
> >>> 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"?
> >
> > 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
> 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 ?

   Yes. IIRC, the paths reported by btrfs subv list are full paths
back to the top level directory of the filesystem. In the case of your
example, that's the same thing.

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
              --- Welcome to Rivendell,  Mr Anderson... ---              

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: strange btrfs sub list output

[Stephane Chazelas]

2011-05-27 10:45:23 +0100, Hugo Mills:
[...]
> > 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(*).
[...]

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.

-- 
Stephane

Re: strange btrfs sub list output

[Hugo Mills]

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

On Fri, May 27, 2011 at 12:30:10PM +0100, Stephane Chazelas wrote:
> 2011-05-27 10:45:23 +0100, Hugo Mills:
> [...]
> > > 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(*).
> [...]
> 
> 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?

   Hm. OK, that's not doing what I thought it was, then. I'll have to
look at the code to work out what that top-level output actually is,
then. (Won't be for a few hours, until I get home from work).

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

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
  --- I hate housework. You make the beds, you wash the dishes, and ---  
           six months later you have to start all over again.            

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: strange btrfs sub list output

[Andreas Philipp]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
On 27.05.2011 13:30, Stephane Chazelas wrote:
> 2011-05-27 10:45:23 +0100, Hugo Mills: [...]
>>> 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(*).
> [...]
>
> 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?

Thanks,
Andreas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJN34/fAAoJEJIcBJ3+XkgiTVcP/iQ62XnEAS0rVGOl+0DNqySb
5A5N3/pzhgzOdMhldJYtgg0K60lV0qs0H31ITgOdGUtpEXibybU/6Yuy2yIfqx0T
3OQCb2KE8la2hlh472aTuIN3beljFYzPu89KVrGaT6kD7lABRXkCG5y1Y5+fvVXI
gtq5/mCqvyaxxUMTppgzLHwtt0YVICZeCDmALMtsVe1DMr0uT5QI0XY+4Glpl7AJ
1G6Plyr7qciOwdRgvM/7NkHl/gsJ4GEvIOSVFiBM4Hb8fX7APy/C//sIPfD2Kg5K
7B6sJMpS2i87uEsrr+w8j7nLWn9Y/255W89r/cG3uISDFRn/RDs9xEnRCfEXb6qf
ZeBPVfv9+pN6mmwrfUOJr4pb44f9/UgTC+udCfzKm1yWVci895NIGsfJgYfA0OOf
GRnCWVRwFStiUGf0uSRH0yJAW5ozI8DzDnDKzByFpMcmw3eVNq5usCftA4XxVi7r
Wu/v9z6DNdHj7ibsSdeYXAmVGpwennILPeEvGWDbMB/OZIDKC3s75yCzXIhxWpya
zR5jGDbGj9IkvUhSAwW0afFqBK+bZny/SJsqA0vFH7Emao0CG1FIJVlN7/S6OSg1
Dtye//ocjhO0kf3OX3hj689n4/mvaBZeVArCz5vJzG2wEcRZTF4DZ4ApsUjne0LC
q4L2n9nLM4yeAs+YjFx/
=R53y
-----END PGP SIGNATURE-----

Re: strange btrfs sub list output

[Stephane Chazelas]

2011-05-27 13:49:52 +0200, Andreas Philipp:
[...]
> > 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?
[...]

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.

-- 
Stephane

Re: strange btrfs sub list output

[C Anthony Risinger]

On Tue, May 31, 2011 at 5:00 AM, Stephane Chazelas
<stephane_chazelas@yahoo.fr> wrote:
> 2011-05-27 13:49:52 +0200, Andreas Philipp:
> [...]
>> > 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?
> [...]
>
> 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.

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?

-- 

C Anthony

Re: strange btrfs sub list output

[Andreas Philipp]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
On 31.05.2011 19:40, C Anthony Risinger wrote:
> On Tue, May 31, 2011 at 5:00 AM, Stephane Chazelas
> <stephane_chazelas@yahoo.fr> wrote:
>> 2011-05-27 13:49:52 +0200, Andreas Philipp: [...]
>>>> 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?
>> [...]
>>
>> 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.
>
> 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?
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.

diff --git a/btrfs-list.c b/btrfs-list.c
index 93766a8..e75d6cf 100644
- --- a/btrfs-list.c
+++ b/btrfs-list.c
@@ -248,6 +248,9 @@ static int resolve_root(struct root_lookup *rl,
struct root_info *ri)
                        top_id = next;
                        break;
                }
+
+               printf("ID %llu top level %llu path %s\n",
ri->root_id, next,
+                              full_path);
        }
        printf("ID %llu top level %llu path %s\n", ri->root_id, top_id,
               full_path);
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJN5Th6AAoJEJIcBJ3+XkgiWNQP/jsWQymukrgESfqndQvrJwl6
QZOe5y9IMmV8jBDPot4EAVAQhLrG2twA1ALVvj+DfD0Ks9VATpmnP4QB39XIWlNz
/cRxoUev/Z8a0zNnXXneUsbJ1rYx5vX6R0yzRWiZ6Yd0EZ9GCRp+HvPRs5NNGGIc
0NZCQk1BOe+MAovSQpUbRtyfd4JcxdPEYkt29VySu2wrD02MdXVyzohegCzmUZWv
ou8COpWvquPmNvYHfudVir6r4BSEfqpIEkkGY61yts00rnnPXuOh1uZQKGyDuK/S
2o6EOAN3SIONEWts7nx95/IjfAbVa/XUmj+bhr2xJspH4Q93tr8rDns0XCCN/GYY
xTfMMUFajZHOhv5qjbUF9BFLAU62eKdw4zCPAmed4f/klBcXZ/Ri1pIBwaJv3CTp
J3camkJBwmTiSwTIIl1qTOMypv0xT602uiiegnBe/UAzz59+cSLDyWFXBc2QQoTV
jhJiLd281kjPqEqALMNJOOZ0pQ6hDxOoBqg7cA5VEY9619coQE93H6UXgtd0E4YX
U32bO7WypGbgd3HuNDWd44p4gVYR/Mzu8symvjJDKg5iChLkBEmYyN8hAGryYhtO
mZBWntTxYPm+Twkf+ovAtVpLGV5Gr1kfGln5lsmsIn1bPW8ZnVbWIDhulD1lQSVw
Th5rDp6lY0ZBe4+mbOXy
=M8dp
-----END PGP SIGNATURE-----

Re: strange btrfs sub list output

[C Anthony Risinger]

On Tue, May 31, 2011 at 1:50 PM, Andreas Philipp
<philipp.andreas@gmail.com> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 31.05.2011 19:40, C Anthony Risinger wrote:
>> On Tue, May 31, 2011 at 5:00 AM, Stephane Chazelas
>> <stephane_chazelas@yahoo.fr> wrote:
>>> 2011-05-27 13:49:52 +0200, Andreas Philipp: [...]
>>>>> 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?
>>> [...]
>>>
>>> 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.
>>
>> 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?
>
> 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.

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?  must have been a fluke/bug in the `btrfs` tool
where a higher level subvol was removed before it's child somehow, is
this correct?  or is the FS itself slightly broken when this happens?

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 prefer
:-)

i'll try this out later tonight, thanks.

... which brings me to a question i've asked a few times in the past
-- will it ever be possible to "replace" subvolid=5 with a different
subvol?  or drop it's contents SAFELY somehow?  lack of this ability
makes it very difficult to rotate a user into an advanced
configuration if they did not install their system into a subvolume to
begin with, and no distro AFAIK does this for them; last time i tried
to `mv` the users installation to an empty subvol it copied everything
for hours ... though this could be fixed already, or possibly
alleviated with `cp --reflink`, i haven't tried for awhile.

i'd like to avoid telling users "ok, now you just need to rm -rf all
the junk from the [btrfs] root, except subvol/dir X, Y, and Z,  else
it will become dead space over time" ... and i just don't feel
comfortable issuing an `rm -rf` on someones system via script.

-- 

C Anthony

Re: strange btrfs sub list output

[C Anthony Risinger]

On Tue, May 31, 2011 at 2:32 PM, C Anthony Risinger <anthony@xtfx.me> w=
rote:
> On Tue, May 31, 2011 at 1:50 PM, Andreas Philipp
> <philipp.andreas@gmail.com> wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 31.05.2011 19:40, C Anthony Risinger wrote:
>>> On Tue, May 31, 2011 at 5:00 AM, Stephane Chazelas
>>> <stephane_chazelas@yahoo.fr> wrote:
>>>> 2011-05-27 13:49:52 +0200, Andreas Philipp: [...]
>>>>>> 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?
>>>> [...]
>>>>
>>>> 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.
>>>
>>> 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?
>>
>> Hopefully, I can help clarify this a little bit. In fact, this is th=
e
>> '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=
mple.
>>
>> 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=
7's
>> parent. Additionally, only test1 and test2 have parent ID 5 or in yo=
ur
>> 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` =
tool
> 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=
pens?
>
> 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=
r
> :-)
>
> i'll try this out later tonight, thanks.

after booting the correct kernel in KVM, this works exactly as
advertised by the commit that added it, and by your explanation --
thanks -- this will be of much use wrt designing "sub-root" layouts
for advanced initramfs recovery options ... i always felt limited by
the requirement to be in the "btrfs root", and mounting by id looses
some flexibility, eg. when trying to use names like pointers/symlinks.

=2E.. now i can put subvols anywhere, and user/script only needs to
determine the stable parent ids once.  nice ... to the laboratory!

--=20

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