All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Murphy <lists@colorremedies.com>
To: Chris Murphy <lists@colorremedies.com>
Cc: "Bearcat Şándor" <bearcatsandor@gmail.com>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: Mixing partitioned and non-partitioned discs in a RAID?
Date: Sat, 20 Aug 2016 09:37:17 -0600	[thread overview]
Message-ID: <CAJCQCtR8rWJHePsBH_oG-V=pSLLztnZY35JyST88_ggasdNrxA@mail.gmail.com> (raw)
In-Reply-To: <CAJCQCtTQAG+0M9AsNj5LNWXTAKd8V-6DL=5kS80dPt59S1uiAA@mail.gmail.com>

On Sat, Aug 20, 2016 at 9:21 AM, Chris Murphy <lists@colorremedies.com> wrote:

>If you
> deleted this udev rule, you run the risk of some boots sometimes
> having a slightly delayed drive becoming available and the volume
> wrongly being mounted degraded when it's not necessary.

Yuck. Revision time!

If you were to delete this udev rule, it's possible to end up with an
unnecessary degraded mount, simply due to a drive spinning up slower
or otherwise having delayed readiness.

Add on: Silently always mounting degraded in order to anticipate
needing unattended degraded mounts will almost certainly lead to data
loss. Btrfs just isn't ready for this yet. It has no concept of device
faulty state still although patches for this are available for testing
(not merged). So yeah, buyer beware. If you don't care about uptime
and unattended operation, just self-healing during normal operation,
then it's OK but you have to remain vigilant, and aware of Btrfs
limitations, including it's lazy repair of formerly missing devices
that reappear. It only fixes passively on reads. To completely fix it,
you have to do a scrub, and you must do it before another drive goes
missing or you can lose the whole file system. Btrfs has no partial
resync like what's offered with mdadm arrays with a write-intent
bitmap.



-- 
Chris Murphy

  reply	other threads:[~2016-08-20 15:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-20  4:00 Mixing partitioned and non-partitioned discs in a RAID? Bearcat Şándor
2016-08-20  6:02 ` Andrei Borzenkov
2016-08-20  6:52 ` Duncan
2016-08-20 15:21 ` Chris Murphy
2016-08-20 15:37   ` Chris Murphy [this message]
     [not found]   ` <BLU437-SMTP168169D258F02597287B2E92170@phx.gbl>
2016-08-21  0:36     ` Chris Murphy
2016-08-21  2:19       ` Duncan
2016-08-21  2:28         ` Bearcat Şándor
2016-09-12 22:21         ` Kai Krakow
2016-09-13  4:07           ` Duncan
2016-09-14 18:21             ` Kai Krakow
2016-09-13 15:55           ` 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='CAJCQCtR8rWJHePsBH_oG-V=pSLLztnZY35JyST88_ggasdNrxA@mail.gmail.com' \
    --to=lists@colorremedies.com \
    --cc=bearcatsandor@gmail.com \
    --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.