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 -- 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
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 -- 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
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. >-- 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
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 -- 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
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 -- 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
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 withActually, 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
-----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----- -- 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
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 -- 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
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
-----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 5Just 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----- -- 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
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... ---
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 -- 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
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.
-----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----- -- 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
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 -- 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
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 -- 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
-----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----- -- 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
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 -- 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
On Tue, May 31, 2011 at 2:32 PM, C Anthony Risinger <anthony@xtfx.me> wrote:> 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.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. ... now i can put subvols anywhere, and user/script only needs to determine the stable parent ids once. nice ... to the laboratory! -- 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