linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Adam Borowski <kilobyte@angband.pl>
To: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
Cc: Hans Deragon <hans@deragon.biz>, linux-btrfs@vger.kernel.org
Subject: Re: raid1: cannot add disk to replace faulty because can only mount fs as read-only.
Date: Fri, 27 Jan 2017 21:28:42 +0100	[thread overview]
Message-ID: <20170127202842.ae2uutz4x45uxmzd@angband.pl> (raw)
In-Reply-To: <fab34ac1-03c0-76ea-eac2-ef4a210a48de@gmail.com>

On Fri, Jan 27, 2017 at 03:03:18PM -0500, Austin S. Hemmelgarn wrote:
> On 2017-01-27 11:47, Hans Deragon wrote:
> > However, as a user, I am seeking for an easy, no maintenance raid
> > solution.  I wish that if a drive fails, the btrfs filesystem still
> > mounts rw and leaves the OS running, but warns the user of the failing
> > disk and easily allow the addition of a new drive to reintroduce
> > redundancy.

> Before I make any suggestions regarding this, I should point out that
> mounting read-write when a device is missing is what caused this issue in
> the first place.  Doing so is extremely dangerous in any RAID setup,
> regardless of your software stack.  The filesystem is expected to store
> things reliably when a write succeeds, and if you've got a broken RAID
> array, claiming that you can store things reliably is generally a lie. MD
> and LVM both have things in place to mitigate most of the risk, but even
> there it's still risky.  Yes, it's not convenient to have to deal with a
> system that won't boot, but it's at least a whole lot easier from Linux than
> it is in most other operating systems.

Now, now.  Other RAID implementations already have this feature that you're
clamoring for!  When it is degraded, they will continue without a hitch, and
perform their duties not even bothering the user.  Then a couple years
later, the other disk will fail.  Obviously, there are no backups -- "we
have RAID".  This is when I get a call.

> The second is proper monitoring.  A well set up monitoring system will let
> you know when the disk is failing before it gets to the point of just
> disappearing from the system most of the time.

No problem, the second busted disk I mentioned above will include a full
mbox with a mail from mdadm for every single day.  They were either unread,
or read by an admin who ignored them and perhaps even wrote a filter to send
them to /dev/null.  Because the system still works, what's the hurry?


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

  reply	other threads:[~2017-01-27 20:29 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-24 18:57 raid1: cannot add disk to replace faulty because can only mount fs as read-only Hans Deragon
2017-01-24 19:48 ` Adam Borowski
     [not found] ` <W75Sc6PDCBok7W75TcCgc7@videotron.ca>
2017-01-27 16:47   ` Hans Deragon
2017-01-27 20:03     ` Austin S. Hemmelgarn
2017-01-27 20:28       ` Adam Borowski [this message]
2017-01-28  9:17       ` Andrei Borzenkov
2017-01-30 12:18         ` Austin S. Hemmelgarn
     [not found]         ` <YAvBcoM9EImXYYAvCcegSf@videotron.ca>
2017-02-01  2:51           ` Hans Deragon
2017-02-01  5:23             ` Duncan
2017-02-01 11:55               ` Adam Borowski
2017-02-01 22:48                 ` Duncan
2017-02-02 12:49                   ` Austin S. Hemmelgarn
2017-02-02 14:25                     ` Adam Borowski
2017-02-02 15:06                       ` Austin S. Hemmelgarn
     [not found]                       ` <ZIyPcL4cW36fIZIyQcB9Hs@videotron.ca>
2017-02-08  3:21                         ` Hans Deragon
2017-02-08 12:50                           ` Austin S. Hemmelgarn
2017-02-08 13:46                             ` Tomasz Torcz
2017-02-08 19:06                               ` Austin S. Hemmelgarn
2017-02-03  9:35                     ` Duncan

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=20170127202842.ae2uutz4x45uxmzd@angband.pl \
    --to=kilobyte@angband.pl \
    --cc=ahferroin7@gmail.com \
    --cc=hans@deragon.biz \
    --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).