From: Chris Murphy <lists@colorremedies.com>
To: Stefanie Leisestreichler <stefanie.leisestreichler@peter-speer.de>
Cc: Hugo Mills <hugo@carfax.org.uk>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: RAID 1 | Newbie Question
Date: Wed, 22 Apr 2020 15:13:20 -0600 [thread overview]
Message-ID: <CAJCQCtTrRshj-oQrJEgaAR=wmuUtTT0fYsFAM0W6QtwUBBgw-Q@mail.gmail.com> (raw)
In-Reply-To: <e000c0cc-132d-04ad-dcfd-d808efbff76d@peter-speer.de>
I haven't looked at the wiki in a bit so I'm not sure if it points out
two common gotchas:
Mismatch between SCT ERC and SCSI driver (used by libata and maybe
also usb) timeouts. Btrfs needs explicit read errors on bad sectors to
do automatic fix ups, same as md.
https://raid.wiki.kernel.org/index.php/Timeout_Mismatch
There's no automatic degraded state for Btrfs. And it is not a good
idea to add the degraded mount option to fstab, as it can result in a
kind of "split brain" corruption. In the case of member device
failure, at startup time the mount will fail and you'll need to
manually mount degraded and fix the problem resulting in the need to
mount degraded. An alternative is maybe modifying the current btrfs
udev rule, to timeout after a decently long period of time to ensure
it's really a case of needing degraded mount, rather than merely a
slow or transient effect that just needs a delay so that all member
devices are available when mount is called. But I don't know if udev
has a concept of waiting. For mdadm this is done in the initramfs.
--
Chris Murphy
next prev parent reply other threads:[~2020-04-22 21:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-22 9:58 RAID 1 | Newbie Question Stefanie Leisestreichler
2020-04-22 10:44 ` Hugo Mills
2020-04-22 10:55 ` Stefanie Leisestreichler
2020-04-22 11:06 ` Hugo Mills
2020-04-22 11:34 ` Stefanie Leisestreichler
2020-04-22 21:13 ` Chris Murphy [this message]
2020-04-23 5:42 ` 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='CAJCQCtTrRshj-oQrJEgaAR=wmuUtTT0fYsFAM0W6QtwUBBgw-Q@mail.gmail.com' \
--to=lists@colorremedies.com \
--cc=hugo@carfax.org.uk \
--cc=linux-btrfs@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;
as well as URLs for NNTP newsgroup(s).