Linux RAID subsystem development
 help / color / mirror / Atom feed
From: Wols Lists <antlists@youngman.org.uk>
To: Stefanie Leisestreichler
	<stefanie.leisestreichler@peter-speer.de>,
	linux-raid@vger.kernel.org
Subject: Re: RAID 1 | Test Booting from /dev/sdb
Date: Tue, 5 May 2020 10:34:54 +0100	[thread overview]
Message-ID: <5EB1333E.1010801@youngman.org.uk> (raw)
In-Reply-To: <608e4d08-a99d-97f3-0476-3a880096f858@peter-speer.de>

On 05/05/20 10:25, Stefanie Leisestreichler wrote:
> 
> On 05.05.20 10:51, Wols Lists wrote:
>>> Change boot medium to /dev/sdb
>>> and do a "mdadm /dev/md0 --add /dev/sda1" to get it recovered again
>>> without loosing the "added" data (i.e. in /var/log) from booting? Also
>>> device identifiers could change I guess. Even if I am fine with loosing
>>> the "added" data from booting with /dev/sdb, will - when booting again
>>> from /dev/sda - /dev/sda be the master in the array again?
>>>
>>> It is not clear to me if I understood correctly in which case which
>>> array member will be the master which will be the base for recovery. Is
>>> it always the HD one booted from?
>>>
>> The "master" if recovery is required will be the "older" one - in this
>> case sda because it was disconnected. HOWEVER. Just check whether you
>> have a bitmap or journal enabled. You can't have both at once, but the
>> result should be that sda rejoins the array cleanly, raid has a record
>> of which writes occurred while it was offline, and it will be updated.
>>
> 
> Does this mean in my scenario /dev/sda1 will come up again and will held
> data in /var/log/ where I can see i.e. log entries which are written
> when the system booted up using /dev/sdb as boot device?

No. The journal or bitmap are stored as part of the array, not the
filesystem. sdb will have a load of "flags" set to say "these blocks
were written to while the array was degraded". So when sda is added back
in, these delayed writes will be copied from sdb to sda.
> 
> I try to be prepared, just in case :-)

Don't we all :-)
> 
> Thanks again for sharing your knowledge, Wols.
> It is highly appreciated.

It's not that deep, but I do try to be clear what I do and don't know
:-) I'm lucky I have a very good memory.

Cheers,
Wol

  reply	other threads:[~2020-05-05  9:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-05  8:11 RAID 1 | Test Booting from /dev/sdb Stefanie Leisestreichler
2020-05-05  8:39 ` Reindl Harald
2020-05-05  8:56   ` Stefanie Leisestreichler
2020-05-05  8:51 ` Wols Lists
2020-05-05  9:25   ` Stefanie Leisestreichler
2020-05-05  9:34     ` Wols Lists [this message]
2020-05-05  9:42       ` Stefanie Leisestreichler
2020-05-05  9:49         ` Reindl Harald

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=5EB1333E.1010801@youngman.org.uk \
    --to=antlists@youngman.org.uk \
    --cc=linux-raid@vger.kernel.org \
    --cc=stefanie.leisestreichler@peter-speer.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