linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roman Mamedov <rm@romanrm.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: RAID1 storage server won't boot with one disk missing
Date: Fri, 18 Sep 2015 00:02:05 +0500	[thread overview]
Message-ID: <20150918000205.6e8f3998@natsu> (raw)
In-Reply-To: <55FAF198.2060106@libero.it>

[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]

On Thu, 17 Sep 2015 19:00:08 +0200
Goffredo Baroncelli <kreijack@libero.it> wrote:

> On 2015-09-17 17:18, Anand Jain wrote:
> >  it looks like -o degraded is going to be a very obvious feature,
> >  I have plans of making it a default feature, and provide -o
> >  nodegraded feature instead. Thanks for comments if any.
> > 
> I am not sure if there is a "good" default for this kind of problem

Yes there is. It is whatever people came to expect from using other RAID
systems and/or generally expect from RAID as a concept.

Both mdadm software RAID, and I believe virtually any hardware RAID controller
out there will let you to successfully boot up and give read-write(!) access
to a RAID in a non-critical failure state, because that's kind of the whole
point of a RAID, to eliminate downtime. If the removed disk is later re-added,
then it is automatically resynced. Mdadm can also make use of its 'write
intent bitmap' to resync only those areas of the array which were in any way
touched during the absence of the newly re-added disk.

If you're concerned that the user "misses" the fact that they have a disk
down, then solve *that*, make some sort of a notify daemon, e.g. mdadm has a
built-in "monitor" mode which sends E-Mail on critical events with any of the
arrays.

-- 
With respect,
Roman

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2015-09-17 19:02 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-16 23:56 RAID1 storage server won't boot with one disk missing erpo41
2015-09-17 15:18 ` Anand Jain
2015-09-17 15:42   ` Chris Murphy
2015-09-17 17:00   ` Goffredo Baroncelli
2015-09-17 19:02     ` Roman Mamedov [this message]
2015-09-17 20:18       ` Chris Murphy
2015-09-18 13:29         ` Austin S Hemmelgarn
2015-09-21 20:00     ` Erkki Seppala
2015-09-18  1:36   ` Duncan
2015-09-18  3:02     ` Gareth Pye
2015-09-21 20:35       ` Erkki Seppala
2015-09-22  5:12         ` Duncan
2015-09-22 11:32         ` Austin S Hemmelgarn
2015-09-22 12:51           ` Qu Wenruo
2015-09-22 13:21             ` Austin S Hemmelgarn
2015-09-22 18:35               ` Chris Murphy
2015-09-22 19:45                 ` Austin S Hemmelgarn
2015-09-17 15:26 ` Chris Murphy

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=20150918000205.6e8f3998@natsu \
    --to=rm@romanrm.net \
    --cc=linux-btrfs@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).