linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Alex Lieflander <atlief@icloud.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] Bypassing LVM Restrictions - RAID6 With Less Than 5 Disks
Date: Sat, 7 May 2022 19:14:50 -0400	[thread overview]
Message-ID: <4D4E1DC0-8A04-474C-8DB2-4C9429F092F2@icloud.com> (raw)
In-Reply-To: <6d72d74a-98cc-b055-d1ba-bcd20201e67@gathman.org>

> On May 7, 2022, at 4:41 PM, Stuart D Gathman wrote:
> 
>> On Fri, 6 May 2022, Alex Lieflander wrote:
>> 
>> Thanks. I really don’t want to give up the DM-Integrity management. Less complexity is just a bonus.
> 
> What are you trying to get out of RAID6?  If redundancy and integrity
> are already managed at another layer, then just use RAID0 for striping.
> 
> I like to use RAID10 for mirror + striping, but I understand parity disks give redundancy without halving capacity.  Parity means RMW cycles of
> largish blocks, whereas straight mirroring (RAID1, RAID10) can write
> single sectors without a RMW cycle.

I don’t trust the hardware I’m running on very much, but it’s all I have to work with at the moment; it’s important that the array is resilient to *any* (and multiple) single chunk corruptions because such corruptions are likely to happen in the future.

For the last several months I’ve periodically been seeing (DM-Integrity) checksum mismatch warnings at various locations on all of my disks. I stopped using a few SATA ports that were explicitly throwing SATA errors, but I suspect that the remaining connections are unpredictably (albeit infrequently) corrupting data in ways that are more difficult to detect.

I’ve tried to “check” and “repair” my array on multiple kernel versions and live recovery USB sticks, but the “check" always seems to freeze and all subsequent IO to the array hangs until reboot; at the moment, a chunk is only ever made consistent when its data is overwritten, so it needs to survive periodic, random corruption for as long as possible.

I also have a disk that infrequently fails to read from a particular area, but the rest of the disk is fine. I wouldn’t trust that disk with valuable data, but it seems like a perfect candidate to hold additional parity (raid6_ls_6) that I hopefully never need.

Alex

_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

  reply	other threads:[~2022-05-07 23:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-27 17:11 [linux-lvm] Bypassing LVM Restrictions - RAID6 With Less Than 5 Disks Alex Lieflander
2022-05-02  0:36 ` John Stoffel
2022-05-02 19:22   ` Alex Lieflander
2022-05-02 21:54     ` John Stoffel
2022-05-07  3:33       ` Alex Lieflander
2022-05-07 20:41         ` Stuart D Gathman
2022-05-07 23:14           ` Alex Lieflander [this message]
2022-05-08 13:25             ` Stuart D Gathman
2022-05-09  0:18             ` John Stoffel

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=4D4E1DC0-8A04-474C-8DB2-4C9429F092F2@icloud.com \
    --to=atlief@icloud.com \
    --cc=linux-lvm@redhat.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;
as well as URLs for NNTP newsgroup(s).