Date: Thu, 4 Nov 1999 23:31:20 +0100 From: Bernd Walter <ticso@cicely.de> To: Kelly Yancey <kbyanc@posi.net> Cc: Greg Lehey <grog@lemis.com>, Mattias Pantzare <pantzer@ludd.luth.se>, freebsd-fs@FreeBSD.ORG Subject: Re: feature list journalled fs Message-ID: <19991104233119.A97812@cicely7.cicely.de> In-Reply-To: <Pine.BSF.4.05.9911041617350.19301-100000@kronos.alcnet.com> References: <19991104161317.49512@mojave.sitaranetworks.com> <Pine.BSF.4.05.9911041617350.19301-100000@kronos.alcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 04, 1999 at 04:26:58PM -0500, Kelly Yancey wrote: > > > Solaris DiskSuite almost extends RAID 5 configruations. You can add disks to a > > > RAID 5 set, but the extra disks will only hold data, no parity. > > > > That's normal for RAID-5. Only one disk in any stripe contains the > > parity information. > > > > Greg > > Except that, if I understand correctly, the new disks don't have parity > for them stored anywhere. They aren't really in on the RAID 5 game, but > tag along and just pretend to be. If you concatenate a single disk to a raid5 set you will have only the raid5 range redundant. You need two or more R1/R5 sets to remain redudand. > > All this talk about extending RAID 5 plexes has got be thinking about > the oft-overlooked RAID 4. I realize this isn't currently implemented in > vinum, but I understand it has similar (although slightly different, not > worse, just different) performance characteristics to RAID 5. But I would > think that RAID 4 would be much simpler to extend because of the fact The simplification shouldn't be that much, but R4 is usually slower because the biggest load is on the parity and with R4 that's not balanced between the disks. > only 1 disk contains the parity; rather than restriping, one only needs to > recalculate parity. No - that's prety much the same if the basic is striping. Beside it should be possible get a concatenated Raid4 layout with vinum if you create a R5 plex with a stripesize equal to the subdisksize. Nevertheless vinums paritylocking is not optimal for this case. R4 is only interesting because you can convert from R0 to R4 and back without the need to copy any datablocks. It shouldn't be much work to implement R4 but who realy needs it. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991104233119.A97812>