linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrei Borzenkov <arvidjaar@gmail.com>
To: Chris Murphy <lists@colorremedies.com>,
	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: Thu, 23 Apr 2020 08:42:33 +0300	[thread overview]
Message-ID: <93197ca4-2c91-8c16-b8df-90a26577b25c@gmail.com> (raw)
In-Reply-To: <CAJCQCtTrRshj-oQrJEgaAR=wmuUtTT0fYsFAM0W6QtwUBBgw-Q@mail.gmail.com>

23.04.2020 00:13, Chris Murphy пишет:
> 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.
> 


mdadm starts per-array systemd timer via udev rule when the first member
device is detected. When this timer triggers (it is expected to trigger
before normal systemd device wait timeout) timer starts service that
effectively calls "mdadm --run".

If btrfs exposed filesystem in sysfs immediately when the first member
device was detected and also checked "mountability" every time member
device is added, similar mechanism could be implemented. Or dedicated
service that makes decision ... the primary problem is that currently
there is no way to know how many devices are there or whether these
devices are enough to mount filesystem even though kernel does know this
information.

      reply	other threads:[~2020-04-23  5:42 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
2020-04-23  5:42           ` Andrei Borzenkov [this message]

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=93197ca4-2c91-8c16-b8df-90a26577b25c@gmail.com \
    --to=arvidjaar@gmail.com \
    --cc=hugo@carfax.org.uk \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.com \
    --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).