All of lore.kernel.org
 help / color / mirror / Atom feed
From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Erkki Seppala <flux-btrfs@inside.org>, linux-btrfs@vger.kernel.org
Subject: Re: RAID1 storage server won't boot with one disk missing
Date: Tue, 22 Sep 2015 07:32:12 -0400	[thread overview]
Message-ID: <56013C3C.6010005@gmail.com> (raw)
In-Reply-To: <m49fv27cxyc.fsf@coffee.modeemi.fi>

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

On 2015-09-21 16:35, Erkki Seppala wrote:
> Gareth Pye <gareth@cerberos.id.au> writes:
>
>> People tend to be looking at BTRFS for a guarantee that data doesn't
>> die when hardware does. Defaults that defeat that shouldn't be used.
>
> However, data is no more in danger at startup than it is at the moment
> when btrfs notices a drive dropping, yet it permits IO to proceed. Is
> there not a contradiction?
>
> Personally I don't see why system startup should be a special case, in
> particular as it can be very stressful situation to recover from when
> RAID is there just to avoid the immediate reaction when hardware breaks;
> and when in practice you can do the recovery while the system is running
> in systems where short service interruptions matter.
>
The difference is that we have code to detect a device not being present 
at mount, we don't have code (yet) to detect it dropping on a mounted 
filesystem.  Why having proper detection for a device disappearing does 
not appear to be a priority, I have no idea, but that is a separate 
issue from mount behavior.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

  parent reply	other threads:[~2015-09-22 11:32 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
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 [this message]
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=56013C3C.6010005@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=flux-btrfs@inside.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.