linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Edmund Urbani <edmund.urbani@liland.com>
To: linux-btrfs@vger.kernel.org
Subject: MD RAID 5/6 vs BTRFS RAID 5/6
Date: Wed, 16 Oct 2019 17:40:10 +0200	[thread overview]
Message-ID: <b665710c-5171-487b-ce38-5ea7075492e4@liland.com> (raw)

Hello everyone,

having recovered most of my data from my btrfs RAID-6, I have by now migrated to
mdadm RAID (with btrfs on top). I am considering switching back to btrfs RAID
some day, when I feel more confident regarding its maturity.

I put some thought into the pros and cons of this choice that I would like to share:

btrfs RAID-5/6:

- RAID write hole issue still unsolved (assuming
https://btrfs.wiki.kernel.org/index.php/RAID56 is up-to-date)
+ can detect and fix bit rot
+ flexibility (resizing / reshaping)
- maturity ? (I had a hard time recovering my data after removal of a drive that
had developed some bad blocks. That's not what I would expect from a RAID-6
setup. To be fair I should point out that I was running kernel 4.14 at the time
and did not do regular scrubbing.)

btrfs on MD RAID 5/6:

+ options to mitigate RAID write hole
- bitrot can only be detected but not fixed
+ mature and proven RAID implementation (based on personal experience of
replacing plenty of drives over the years without data loss)

I would be interested in getting your feedback on this comparison. Do you agree
with my observations? Did I miss anything you would consider important?

Regards,
 Edmund





-- 
*Liland IT GmbH*


Ferlach ● Wien ● München
Tel: +43 463 220111
Tel: +49 89 
458 15 940
office@Liland.com
https://Liland.com <https://Liland.com> 



Copyright © 2019 Liland IT GmbH 

Diese Mail enthaelt vertrauliche und/oder 
rechtlich geschuetzte Informationen. 
Wenn Sie nicht der richtige Adressat 
sind oder diese Email irrtuemlich erhalten haben, informieren Sie bitte 
sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren 
sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. 

This 
email may contain confidential and/or privileged information. 
If you are 
not the intended recipient (or have received this email in error) please 
notify the sender immediately and destroy this email. Any unauthorised 
copying, disclosure or distribution of the material in this email is 
strictly forbidden.


             reply	other threads:[~2019-10-16 15:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-16 15:40 Edmund Urbani [this message]
2019-10-16 19:42 ` MD RAID 5/6 vs BTRFS RAID 5/6 Zygo Blaxell
2019-10-21 15:27   ` Edmund Urbani
2019-10-21 19:34     ` Zygo Blaxell
2019-10-23 16:32       ` Edmund Urbani
2019-10-26  0:01         ` Zygo Blaxell
2019-10-17  4:07 ` Jon Ander MB
2019-10-17 15:57   ` Chris Murphy
2019-10-17 18:23     ` Graham Cobb
2019-10-20 21:41       ` Chris Murphy
2019-10-18 22:19     ` Supercilious Dude
     [not found]     ` <CAGmvKk4wENpDqLFZG+D8_zzjhXokjMfdbmgTKTL49EFcfdVEtQ@mail.gmail.com>
2019-10-20 21:43       ` 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=b665710c-5171-487b-ce38-5ea7075492e4@liland.com \
    --to=edmund.urbani@liland.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 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).