Date:   Tue, 14 Feb 2023 23:23:04 -0800
From:   Kyle Sanderson <kyle.leet@...il.com>
To:     Roger Heflin <rogerheflin@...il.com>
Cc:     Heinz Mauelshagen <heinzm@...hat.com>, linux-raid@...r.kernel.org,
        Song Liu <song@...nel.org>,
        device-mapper development <dm-devel@...hat.com>,
        John Stoffel <john@...ffel.org>,
        Linux-Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [dm-devel] RAID4 with no striping mode request

> On Tue, Feb 14, 2023 at 2:28 PM Roger Heflin <rogerheflin@...il.com> wrote:
>
> 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.
>
> 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..

Exactly, each disk operates completely independently (so a XFS
partition per disk on each md device). So I have 4 disks presently, 3
are data, and one is dedicated parity. I can scale up or down these
disks freely, changing the physical data disk sizes and still have
them all protected by the single parity disk by removing and adding
them to the array.

> On Tue, Feb 14, 2023 at 6:23 PM Heinz Mauelshagen <heinzm@...hat.com> wrote:
>
> as any of the currently implemented 'parity' algorithms (block xor/P-/Q-Syndrome) provided by DM/MD RAID
> have to have at least two data blocks to calculate:  are you, apart from the filesystem thoughts you bring up, thinking
> about running those on e.g. pairs of disks of mentioned even numbered set of 8?

Users of these appliances today gain "parity" by adding the second
disk (note it must be the equal to or the largest in the array), and
can scale by adding disk by disk individually (so 3, 4, 5, 6...).

Hopefully it's starting to make more sense now.

On Tue, Feb 14, 2023 at 2:28 PM Roger Heflin <rogerheflin@...il.com> wrote:
>
> On Tue, Feb 14, 2023 at 3:27 PM Heinz Mauelshagen <heinzm@...hat.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.
>
> 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.
>
> 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.

Powered by blists - more mailing lists