On Tue, May 31, 2011 at 1:50 PM, Andreas Philipp <philipp.andr...@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_chaze...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
