On Tue, May 31, 2011 at 2:32 PM, C Anthony Risinger <anthony@xxxxxxx> wrote: > On Tue, May 31, 2011 at 1:50 PM, Andreas Philipp > <philipp.andreas@xxxxxxxxx> 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@xxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
