Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Ochi <ochi@arcor.de>, lists@colorremedies.com
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Creating btrfs RAID on LUKS devs makes devices disappear
Date: Fri, 12 May 2017 07:25:16 -0400	[thread overview]
Message-ID: <ba7f8443-6031-6658-d63b-e09dd3f2259e@gmail.com> (raw)
In-Reply-To: <4b7809e0-7329-62b0-c488-51bd4f0318a6@arcor.de>

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).


  reply	other threads:[~2017-05-12 11:25 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-11 20:17 Creating btrfs RAID on LUKS devs makes devices disappear Ochi
2017-05-11 20:36 ` Ochi
2017-05-11 22:24   ` Chris Murphy
2017-05-11 23:24     ` Ochi
2017-05-12 11:25       ` Austin S. Hemmelgarn [this message]
2017-05-12 13:54         ` Ochi
2017-05-12 14:11           ` Austin S. Hemmelgarn
2017-05-12 17:07       ` Chris Murphy
2017-05-13  7:29         ` Andrei Borzenkov
2017-05-13 15:28           ` Ochi
2017-05-13 18:51             ` Andrei Borzenkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ba7f8443-6031-6658-d63b-e09dd3f2259e@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.com \
    --cc=ochi@arcor.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox