From: Wols Lists <antlists@youngman.org.uk>
To: Roger Heflin <rogerheflin@gmail.com>,
Heinz Mauelshagen <heinzm@redhat.com>
Cc: Kyle Sanderson <kyle.leet@gmail.com>,
linux-raid@vger.kernel.org,
device-mapper development <dm-devel@redhat.com>,
Linux-Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [dm-devel] RAID4 with no striping mode request
Date: Wed, 15 Feb 2023 09:40:26 +0000 [thread overview]
Message-ID: <cbce8455-ed12-4bfa-427e-4dd54f19dca9@youngman.org.uk> (raw)
In-Reply-To: <CAAMCDeeHxMBoVkNYAyssjgjo4=FYd2NonS-mqC7OUEL89B9Cig@mail.gmail.com>
On 14/02/2023 22:28, Roger Heflin wrote:
> On Tue, Feb 14, 2023 at 3:27 PM Heinz Mauelshagen <heinzm@redhat.com> wrote:
>>
>
>>
>>
>> ...which is RAID1 plus a parity disk which seems superfluous as you achieve (N-1)
>> resilience against single device failures already without the later.
>>
>> What would you need such parity disk for?
>>
>> Heinz
>>
>
> I thought that at first too, but threw that idea out as it did not
> make much sense.
>
> What he appears to want is 8 linear non-striped data disks + a parity disk.
>
> Such that you can lose any one data disk and parity can rebuild that
> disk. And if you lose several data diskis, then you have intact
> non-striped data for the remaining disks.
But all your lost disks are lost (until you rebuild parity. The lost
disks are still lost, but you won't lose any more, unless lightning
strikes twice).
>
> It would almost seem that you would need to put a separate filesystem
> on each data disk/section (or have a filesystem that is redundant
> enough to survive) otherwise losing an entire data disk would leave
> the filesystem in a mess..
>
> So N filesystems + a parity disk for the data on the N separate
> filesystems. And each write needs you to read the data from the disk
> you are writing to, and the parity and recalculate the new parity and
> write out the data and new parity.
>
> If the parity disk was an SSD it would be fast enough, but if parity
> was an SSD I would expect it to get used up/burned out from all of
> parity being re-written for each write on each disk unless you bought
> an expensive high-write ssd.
I think even cheap SSDs are okay now ...
>
> The only advantage of the setup is that if you lose too many disks you
> still have some data.
>
> It is not clear to me that it would be any cheaper if parity needs to
> be a normal ssd's (since ssds are about 4x the price/gb and high-write
> ones are even more) than a classic bunch of mirrors, or even say a 4
> disks raid6 where you can lose any 2 and still have data.
The only (claimed) advantage of the setup is that you can mix and match
disk sizes. Personally, I'd just raid-0 the smaller disks to get a whole
bunch of volumes roughly equal to the largest disk, raid-5 or -6 those
together, and put LVM on the top.
Probably split two disks out to mirror as my / partition away from the
main /home raid/lvm.
This scheme is just too hare-brained imho.
(Oh, and if one drive fails and the others carry on writing, you run the
serious risk of screwing up parity and losing your lost disk, anyway.
It's just not robust in the face of glitches ...)
Cheers,
Wol
next prev parent reply other threads:[~2023-02-15 9:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-13 3:07 Kyle Sanderson
2023-02-13 19:40 ` John Stoffel
2023-02-13 21:11 ` Kyle Sanderson
2023-02-14 18:37 ` Song Liu
[not found] ` <CAM23Vxr8LkkcVDFfW1=qEYGgo7JG1qx62eWSV4WOw4_MnD+TZA@mail.gmail.com>
2023-02-14 22:28 ` [dm-devel] " Roger Heflin
2023-02-15 7:23 ` Kyle Sanderson
2023-02-15 9:40 ` Wols Lists [this message]
[not found] ` <CAM23VxpzY6qYsdTYxe01FT7AJvEbODf8X_vq8ALL35TfyrB8xQ@mail.gmail.com>
2023-02-15 11:44 ` Roger Heflin
2023-02-15 14:53 ` Wols Lists
2023-02-15 15:22 ` Roger Heflin
2023-02-16 0:01 ` Kyle Sanderson
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=cbce8455-ed12-4bfa-427e-4dd54f19dca9@youngman.org.uk \
--to=antlists@youngman.org.uk \
--cc=dm-devel@redhat.com \
--cc=heinzm@redhat.com \
--cc=kyle.leet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=rogerheflin@gmail.com \
/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
all inboxes | Powered by JetHome®