Re: Creating btrfs RAID on LUKS devs makes devices disappear

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2017-05-12 09:54, Ochi wrote:
> On 12.05.2017 13:25, Austin S. Hemmelgarn wrote:
>> On 2017-05-11 19:24, Ochi wrote:
>>> Hello,
>>>
>>> here is the journal.log (I hope). It's quite interesting. I rebooted the
>>> machine, performed a mkfs.btrfs on dm-{2,3,4} and dm-3 was missing
>>> afterwards (around timestamp 66.*). However, I then logged into the
>>> machine from another terminal (around timestamp 118.*) which triggered
>>> something to make the device appear again :O Indeed, dm-3 was once again
>>> there after logging in. Does systemd mix something up?
>>>
>>> Hmm, I just did another mkfs once the devices where back, devices were
>>> missing, but they re-appeared a few seconds later, without logging into
>>> a terminal. After another mkfs, they were gone again and are now still
>>> gone after waiting a few minutes. It's really weird, I can't really tell
>>> what triggers this yet. Will test more tomorrow, let me know if you have
>>> any more ideas what to try.
>>
>> It looks like something made systemd think that it should tear down
>> the LUKS volumes, but it somehow only got /dev/dm-3 and not the
>> others, and then you logging in and triggering the creation of the
>> associated user slice somehow made it regain it's senses.  Next time
>> you see it disappear, try checking `systemctl status` for the unit you
>> have set up for the LUKS volume and see what that says.  I doubt it
>> will give much more info, but I suspect it will say it's stopped,
>> which will solidify that systemd is either misconfigured or doing
>> something stupid (and based on past experience, I'm willing to bet
>> it's the latter).
>
> I will take a closer look at systemd when I get home. I would like to
> point out that this sounds very related to these fairly recent systemd
> issues:
>
> https://github.com/systemd/systemd/issues/5781
>
> https://github.com/systemd/systemd/issues/5866
>
> So my best guess is that systemd is indeed doing weird stuff with
> multi-device btrfs volumes.
Oh, it's known that systemd does weird stuff with multi-device setups, 
even if they aren't BTRFS, but this is odd behavior that I've not seen 
anything about before (I don't use systemd myself except on the 
reference VM's I have for the various distros that use it by default, so 
I end up hearing about this stuff through word of mouth).

That said, some of the discussion in that first issue you mentioned 
actually provides a possible explanation for some of the issues existing 
at all, namely that there appears to be a disconnect between how BTRFS 
actually behaves and how the systemd developers thinks it behaves (the 
question from Pottering about what's doing the 'assembly' is 
particularly interesting, given that there is nothing other than the 
kernel that does the equivalent of the 'assembly' step for an MD array 
or scanning for an LVM array).