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
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
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
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.
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
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
From: Hugo Mills <hidden> Date: 2011-05-27 09:12:24
On Fri, May 27, 2011 at 09:47:33AM +0100, Stephane Chazelas wrote:
2011-05-27 10:21:03 +0200, Andreas Philipp:
[...]
quoted
quoted
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
From: Andreas Philipp <hidden> Date: 2011-05-27 09:24:48
-----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:
quoted
2011-05-27 10:21:03 +0200, Andreas Philipp:
[...]
quoted
quoted
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-----
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
From: Hugo Mills <hidden> Date: 2011-05-27 09:45:23
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]
quoted
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
From: Andreas Philipp <hidden> Date: 2011-05-27 10:06:44
-----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:
quoted
2011-05-27 10:12:24 +0100, Hugo Mills:
[skipped useful clarification]
quoted
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"?
quoted
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-----
From: Hugo Mills <hidden> Date: 2011-05-27 10:29:19
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:
quoted
On Fri, May 27, 2011 at 10:30:29AM +0100, Stephane Chazelas wrote:
quoted
2011-05-27 10:12:24 +0100, Hugo Mills:
[skipped useful clarification]
quoted
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"?
quoted
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... ---
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
From: Hugo Mills <hidden> Date: 2011-05-27 11:38:43
On Fri, May 27, 2011 at 12:30:10PM +0100, Stephane Chazelas wrote:
2011-05-27 10:45:23 +0100, Hugo Mills:
[...]
quoted
quoted
How could a "subvolume 285" become a "top level"?
quoted
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.
From: Andreas Philipp <hidden> Date: 2011-05-27 11:49:52
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 27.05.2011 13:30, Stephane Chazelas wrote:
2011-05-27 10:45:23 +0100, Hugo Mills: [...]
quoted
quoted
How could a "subvolume 285" become a "top level"?
quoted
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-----
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
From: C Anthony Risinger <hidden> Date: 2011-05-31 17:40:04
On Tue, May 31, 2011 at 5:00 AM, Stephane Chazelas
[off-list ref] wrote:
2011-05-27 13:49:52 +0200, Andreas Philipp:
[...]
quoted
quoted
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
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
From: Andreas Philipp <hidden> Date: 2011-05-31 18:50:34
-----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
[off-list ref] wrote:
quoted
2011-05-27 13:49:52 +0200, Andreas Philipp: [...]
quoted
quoted
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
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.
From: C Anthony Risinger <hidden> Date: 2011-05-31 19:32:02
On Tue, May 31, 2011 at 1:50 PM, Andreas Philipp
[off-list ref] wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 31.05.2011 19:40, C Anthony Risinger wrote:
quoted
On Tue, May 31, 2011 at 5:00 AM, Stephane Chazelas
[off-list ref] wrote:
quoted
2011-05-27 13:49:52 +0200, Andreas Philipp: [...]
quoted
quoted
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
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
From: C Anthony Risinger <hidden> Date: 2011-06-02 06:23:09
On Tue, May 31, 2011 at 2:32 PM, C Anthony Risinger [off-list ref] w=
rote:
On Tue, May 31, 2011 at 1:50 PM, Andreas Philipp
[off-list ref] wrote:
quoted
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 31.05.2011 19:40, C Anthony Risinger wrote:
quoted
On Tue, May 31, 2011 at 5:00 AM, Stephane Chazelas
[off-list ref] wrote:
quoted
2011-05-27 13:49:52 +0200, Andreas Philipp: [...]
quoted
quoted
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
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
quoted
'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.
quoted
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
quoted
parent. Additionally, only test1 and test2 have parent ID 5 or in yo=
ur
quoted
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