linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Steigerwald <martin@lichtvoll.de>
To: Chris Murphy <lists@colorremedies.com>
Cc: Stefan K <shadow_7@gmx.net>, Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs as / filesystem in RAID1
Date: Thu, 07 Feb 2019 18:37:07 +0100	[thread overview]
Message-ID: <2840929.O1qc6pvfHa@merkaba> (raw)
In-Reply-To: <CAJCQCtRuUBfhXQGr29hmOU1mW1wU2jSvr+dun72NAw3O28=cyA@mail.gmail.com>

Chris Murphy - 07.02.19, 18:15:
> > So please change the normal behavior
> 
> In the case of no device loss, but device delay, with 'degraded' set
> in fstab you risk a non-deterministic degraded mount. And there is no
> automatic balance (sync) after recovering from a degraded mount. And
> as far as I know there's no automatic transition from degraded to
> normal operation upon later discovery of a previously missing device.
> It's just begging for data loss. That's why it's not the default.
> That's why it's not recommended.

Still the current behavior is not really user-friendly. And does not 
meet expectations that users usually have about how RAID 1 works. I know 
BTRFS RAID 1 is no RAID 1, although it is called like this.

I also somewhat get that with the current state of BTRFS the current 
behavior of not allowing a degraded mount may be better… however… I see 
clearly room for improvement here. And there very likely will be 
discussions like this on this list… until BTRFS acts in a more user 
friendly way here.

I faced this myself during recovery from a failure of one SSD of a dual 
SSD BTRFS RAID 1 and it caused me having to spend *hours* instead of 
what in my eyes could be minutes to recover the machine to a working 
state again. Luckily the SSDs I use do not tend to fail all that often. 
And the Intel SSD 320 that has this "Look, I am 8 MiB big and all your 
data is gone" firmware bug – even with the firmware version that was 
supposed to fix this issue – is out of service now. Although I was able 
to bring it back to a working (but blank) state with a secure erase, I 
am just not going to use such a SSD for anything serious.

Thanks,
-- 
Martin



  reply	other threads:[~2019-02-07 17:44 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-01 10:28 btrfs as / filesystem in RAID1 Stefan K
2019-02-01 19:13 ` Hans van Kranenburg
2019-02-07 11:04   ` Stefan K
2019-02-07 12:18     ` Austin S. Hemmelgarn
2019-02-07 18:53       ` waxhead
2019-02-07 19:39         ` Austin S. Hemmelgarn
2019-02-07 21:21           ` Remi Gauvin
2019-02-08  4:51           ` Andrei Borzenkov
2019-02-08 12:54             ` Austin S. Hemmelgarn
2019-02-08  7:15           ` Stefan K
2019-02-08 12:58             ` Austin S. Hemmelgarn
2019-02-08 16:56             ` Chris Murphy
2019-02-08 18:10           ` waxhead
2019-02-08 19:17             ` Austin S. Hemmelgarn
2019-02-09 12:13               ` waxhead
2019-02-10 18:34                 ` Chris Murphy
2019-02-11 12:17                   ` Austin S. Hemmelgarn
2019-02-11 21:15                     ` Chris Murphy
2019-02-08 20:17             ` Chris Murphy
2019-02-07 17:15     ` Chris Murphy
2019-02-07 17:37       ` Martin Steigerwald [this message]
2019-02-07 22:19         ` Chris Murphy
2019-02-07 23:02           ` Remi Gauvin
2019-02-08  7:33           ` Stefan K
2019-02-08 17:26             ` Chris Murphy
2019-02-11  9:30     ` Anand Jain
2019-02-02 23:35 ` Chris Murphy
2019-02-04 17:47   ` Patrik Lundquist
2019-02-04 17:55     ` Austin S. Hemmelgarn
2019-02-04 22:19       ` Patrik Lundquist
2019-02-05  6:46         ` Chris Murphy
2019-02-05  7:37           ` 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=2840929.O1qc6pvfHa@merkaba \
    --to=martin@lichtvoll.de \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.com \
    --cc=shadow_7@gmx.net \
    /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).