From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3B092C636D4 for ; Wed, 15 Feb 2023 09:40:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233987AbjBOJkl (ORCPT ); Wed, 15 Feb 2023 04:40:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46536 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232248AbjBOJkj (ORCPT ); Wed, 15 Feb 2023 04:40:39 -0500 Received: from smtp.hosts.co.uk (smtp.hosts.co.uk [85.233.160.19]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5D9CA23D85; Wed, 15 Feb 2023 01:40:28 -0800 (PST) Received: from host86-157-192-115.range86-157.btcentralplus.com ([86.157.192.115] helo=[192.168.1.218]) by smtp.hosts.co.uk with esmtpa (Exim) (envelope-from ) id 1pSEH4-0009mu-Bn; Wed, 15 Feb 2023 09:40:26 +0000 Message-ID: Date: Wed, 15 Feb 2023 09:40:26 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [dm-devel] RAID4 with no striping mode request To: Roger Heflin , Heinz Mauelshagen Cc: Kyle Sanderson , linux-raid@vger.kernel.org, device-mapper development , Linux-Kernel References: <25578.37401.314298.238192@quad.stoffel.home> Content-Language: en-GB From: Wols Lists In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 14/02/2023 22:28, Roger Heflin wrote: > On Tue, Feb 14, 2023 at 3:27 PM Heinz Mauelshagen 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