Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 2 Mar 1998 23:57:44 +0100 (MET)
From:      Wilko Bulte <wilko@yedi.iaf.nl>
To:        grog@lemis.com (Greg Lehey)
Cc:        sbabkin@dcn.att.com, tlambert@primenet.com, shimon@simon-shapiro.org, jdn@acp.qiv.com, blkirk@float.eli.net, hackers@FreeBSD.ORG
Subject:   Re: SCSI Bus redundancy...
Message-ID:  <199803022257.XAA06604@yedi.iaf.nl>
In-Reply-To: <19980303084608.56831@freebie.lemis.com> from Greg Lehey at "Mar 3, 98 08:46:08 am"

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803022257.XAA06604>