public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Marc MERLIN <marc@merlins.org>
To: Roman Mamedov <rm@romanrm.net>
Cc: Andrea Gelmini <andrea.gelmini@gmail.com>,
	Andrei Borzenkov <arvidjaar@gmail.com>,
	Zygo Blaxell <ce3g8jdj@umail.furryterror.org>,
	Josef Bacik <josef@toxicpanda.com>,
	Chris Murphy <lists@colorremedies.com>,
	Qu Wenruo <quwenruo.btrfs@gmx.com>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: Suggestions for building new 44TB Raid5 array
Date: Sun, 12 Jun 2022 10:31:24 -0700	[thread overview]
Message-ID: <20220612173124.GJ1664812@merlins.org> (raw)
In-Reply-To: <20220611225416.25c8a8d6@nvm>

On Sat, Jun 11, 2022 at 10:54:16PM +0500, Roman Mamedov wrote:
> On Sat, 11 Jun 2022 07:52:59 -0700
> Marc MERLIN <marc@merlins.org> wrote:
> 
> > 1) mdadm --create /dev/md7 --level=5 --consistency-policy=ppl
> > --raid-devices=5 /dev/sd[abdef]1 --chunk=256 --bitmap=internal
> 
> One more thing I wanted to mention, did you have PPL on your previous array?
> Or it was not implemented yet back then? I know it is supposed to protect
> against the write hole, which could have caused your previous FS corruption.
 
Looks like I had internal bitmap instead
gargamel:~# mdadm --query --detail  /dev/md7
/dev/md7:
           Version : 1.2
     Creation Time : Sun Feb 11 20:38:30 2018
        Raid Level : raid5
        Array Size : 23441561600 (22355.62 GiB 24004.16 GB)
     Used Dev Size : 5860390400 (5588.90 GiB 6001.04 GB)
      Raid Devices : 5
     Total Devices : 5
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Fri Jun 10 12:09:08 2022
             State : clean 
    Active Devices : 5
   Working Devices : 5
    Failed Devices : 0
     Spare Devices : 0

            Layout : left-symmetric
        Chunk Size : 512K

Consistency Policy : bitmap

I'll switch PPL instead, thanks for that. Actually I need to migrate
my other raid5 arrays to that too. It looks like it can be done at runtime.

> Yes, but in MergerFS each file is stored entirely within a single disk,
> there's no striping. So only files which happened to be on the failed disk are
> lost and need to be restored from backups. For this it helps to keep track of
> what was where, with something like "find /mnt/ > `date`.lst" in crontab.

Right, I figured. It's not bad, but I do want no data loss if I lose a
drive, so I'll take raid5.
I realize that filesystem aware raid5, like the raid5 in btrfs which I'm
not sure I can really trust, still? , could lay out the files to be one per disk
without striping.

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
 
Home page: http://marc.merlins.org/                       | PGP 7F55D5F27AAF9D08

  reply	other threads:[~2022-06-12 17:31 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-11  4:51 Suggestions for building new 44TB Raid5 array Marc MERLIN
2022-06-11  9:30 ` Roman Mamedov
     [not found]   ` <CAK-xaQYc1PufsvksqP77HMe4ZVTkWuRDn2C3P-iMTQzrbQPLGQ@mail.gmail.com>
2022-06-11 14:52     ` Marc MERLIN
2022-06-11 17:54       ` Roman Mamedov
2022-06-12 17:31         ` Marc MERLIN [this message]
2022-06-12 21:21       ` Roman Mamedov
2022-06-13 17:46         ` Marc MERLIN
2022-06-13 18:06           ` Roman Mamedov
2022-06-14  4:51             ` Marc MERLIN
2022-06-13 18:10           ` Zygo Blaxell
2022-06-13 18:13         ` Marc MERLIN
2022-06-13 18:29           ` Roman Mamedov
2022-06-13 20:08           ` Zygo Blaxell
2022-06-14  6:36             ` Torbjörn Jansson
2022-06-20 20:37       ` Andrea Gelmini
2022-06-21  5:26         ` Zygo Blaxell
2022-07-06  9:09           ` Andrea Gelmini
2022-06-11 23:44 ` Zygo Blaxell
2022-06-14 11:03 ` ronnie sahlberg
     [not found] ` <5e1733e6-471e-e7cb-9588-3280e659bfc2@aqueos.com>
2022-06-20 15:01   ` Marc MERLIN
2022-06-20 15:52     ` Ghislain Adnet
2022-06-20 16:27       ` Marc MERLIN
2022-06-20 17:02     ` Andrei Borzenkov
2022-06-20 17:26       ` Marc MERLIN

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=20220612173124.GJ1664812@merlins.org \
    --to=marc@merlins.org \
    --cc=andrea.gelmini@gmail.com \
    --cc=arvidjaar@gmail.com \
    --cc=ce3g8jdj@umail.furryterror.org \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.com \
    --cc=quwenruo.btrfs@gmx.com \
    --cc=rm@romanrm.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