From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Austin S Hemmelgarn <ahferroin7@gmail.com>,
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 20:51:22 +0800 [thread overview]
Message-ID: <56014ECA.1050002@gmx.com> (raw)
In-Reply-To: <56013C3C.6010005@gmail.com>
在 2015年09月22日 19:32, Austin S Hemmelgarn 写道:
> 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.
>
Sorry for jumping out for such a sudden, but I submitted a patchset
which is somewhat related to such degraded case.
[PATCH 0/5] Btrfs: Per-chunk degradable check
With that patchset, btrfs can do quite good check for degradable and
mount/remount and even mounted time.
(Return value of btrfs_check_degradable() will indicate all devices OK,
or not all OK but degradable, or not writable degradable)
And with that patchset, it's quite easy to add support for btrfs to
sliently switch to degraded mount option if possible.
(Along with other improvement of course)
For the original feedback from end user, personally I understand users
who don't want to add degraded mount option manually when a device
fails, nor don't want to add a permanent mount option info fstab, just
in case of failure.
So personally, I'd like to add a new mount option "nodegraded", to allow
user to force no degraded mount.
And if neither "degraded" nor "nondegraded" is given, let btrfs to
automatically switch to degraded if possible.
And it should also still be able to info user, either by the easily
igored dmesg, or easier to notice mount option change.
How about this method to solve the problem?
Thanks,
Qu
next prev parent reply other threads:[~2015-09-22 12:51 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
2015-09-22 12:51 ` Qu Wenruo [this message]
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=56014ECA.1050002@gmx.com \
--to=quwenruo.btrfs@gmx.com \
--cc=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 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).