From owner-freebsd-hackers Tue Mar 3 00:16:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA25680 for freebsd-hackers-outgoing; Tue, 3 Mar 1998 00:16:25 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id AAA25672 for ; Tue, 3 Mar 1998 00:16:21 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: by uni4nn.gn.iaf.nl with UUCP id AA32589 (5.67b/IDA-1.5 for hackers@freebsd.org); Tue, 3 Mar 1998 09:15:16 +0100 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.7/8.6.12) id XAA06604; Mon, 2 Mar 1998 23:57:44 +0100 (MET) From: Wilko Bulte Message-Id: <199803022257.XAA06604@yedi.iaf.nl> Subject: Re: SCSI Bus redundancy... In-Reply-To: <19980303084608.56831@freebie.lemis.com> from Greg Lehey at "Mar 3, 98 08:46:08 am" To: grog@lemis.com (Greg Lehey) Date: Mon, 2 Mar 1998 23:57:44 +0100 (MET) Cc: sbabkin@dcn.att.com, tlambert@primenet.com, shimon@simon-shapiro.org, jdn@acp.qiv.com, blkirk@float.eli.net, hackers@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL32 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As Greg Lehey wrote... > On Mon, 2 March 1998 at 14:23:50 -0500, sbabkin@dcn.att.com wrote: > >> ---------- > >> From: Terry Lambert[SMTP:tlambert@primenet.com] > >> > >>>>> I think Julian's SLICE code has something in that direction. > >> DPT > >>>>> supports INCREASING the size of a RAID-5 array by adding drives. > >>>> > >>>> How can that work? > >>> > >>> Something like > >>> - read N RAID blocks from K disks > >>> - compute new checksum for K+1 disks and write as less number > >>> of RAID blocks but each one of bigger size (K+1/K times) > >>> - add empty blocks at the end of RAID in the added space > >> > >> You would have to remember to grab the blocks to be relocated with > >> the same O(n) randomness as their allocation. 8-). > >> > > Huh ? Probably I've missed something about RAIDs. I've thought > > that, for example, RAID block 0 consists of blocks 0 of all > > the physical disks. And so on. And I've thought that RAID itself > > does not allocate any blocks, the upper level like filesystem or > > volume manager does it, RAID just makes chechsuming. Am I wrong again ? > > That's not the point. OK, we were talking about RAID 5 here, which > also has parity blocks, but the point is that if you add another disk, > you're effectively adding another block every n blocks in the file > system address space. It requires some non-trivial data movement to > rearrange all the data (more specifically, except for the first n (n = > old number of drives) blocks, you must move *everything*, and you must > recalculate parity for every stripe. > > My question ("How can that work?") was based on the misassumption that > this would be too much work to be justifiable. And apart from the work involved to get it implemented: how long would it take a RAIDset to get re-organised/enlarged. Reason #1 for doing things like this is because you don't want downtime. And I don't want to think about some hardware failure (say a disk) halfway during this process. That would really result in a dis[k]array ;-) 'Not everything that can be done should be done' Wilko _ ______________________________________________________________________ | / o / / _ Bulte email: wilko @ yedi.iaf.nl http://www.tcja.nl/~wilko |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' --------------- Support your local daemons: run [Free,Net,Open]BSD Unix -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message