Re: strange btrfs sub list output

[C Anthony Risinger <anthony@xtfx.me>]

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