Date: Thu, 4 Nov 1999 16:58:21 -0500 (EST) From: Kelly Yancey <kbyanc@posi.net> To: Greg Lehey <grog@lemis.com> Cc: freebsd-fs@FreeBSD.ORG Subject: Re: feature list journalled fs Message-ID: <Pine.BSF.4.05.9911041647050.19966-100000@kronos.alcnet.com> In-Reply-To: <19991104163941.53462@mojave.sitaranetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 4 Nov 1999, Greg Lehey wrote: > On Thursday, 4 November 1999 at 16:26:58 -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. > > Ah. What reason do you have to assume that that's the case? I just thought that was what he meant by "but the extra disks will only hold data, no parity". In RAID 5, all disks will hold a portion of the parity information. > > > 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. > > It has worse performance characteristics than RAID-5. It also has no > redeeming virtues, except possibly code simplicity. I've even had hardware which supported it (always just 0, 1, 0/1, and 5), so I don't have any practical experience (read "arm waving"), but I have read (mainly in Adaptec paraphenalia) that RAID 4 is supposed to have slightly better read characteristics. > > > But I would think that RAID 4 would be much simpler to extend > > because of the fact only 1 disk contains the parity; rather than > > restriping, one only needs to recalculate parity. > > No, the effort is the same. It's not recalculating parity that's the > killer, it's moving all the data around. Consider the first stripe in > the plex (which looks identical for RAID-4 and RAID-5): > > Disk 1 2 3 4 5 6 7 8 9 > --------------------------------------------------------- > | | | | | | | | P | > --------------------------------------------------------- > > You have a storage of 7 blocks, each of stripe size (say 7 MB for a 1 > MB stripe size). The first stripe contains the data for 0 to 6 MB, > the second stripe contains the data for 7 to 13 MB, the third for 14 > to 20, and so on. > > Add a disk and you get: > > ------------------------------------------------------------------ > | | | | | | | | | P | > ------------------------------------------------------------------ > > Now the first stripe must contain the data for 0 to 7 MB, the second > stripe for 8 to 15 MB, the third for 16 to 23, and so on. See the > problem? Recalculating parity is only part of it, and deciding where > it ends up (stays on disk 8 for RAID-4, moves to a possibly different > place for RAID-5) is trivial. > > Greg I was thinking that with RAID 4 specifying a single disk to hold all parity information, the volume manager would record which disk held the parity information (disk 8 in your example above) so adding another disk would result in: ------------------------------------------------------------------ | | | | | | | | P | | ------------------------------------------------------------------ Which looks odd, but would work, right? Then only parity would need to be recalculated. It only doesn't work with RAID 5 because the data is supposed to be distributed uniformly across the disks, so restriping is required. Kelly -- Kelly Yancey - kbyanc@posi.net - Richmond, VA Director of Technical Services, ALC Communications http://www.alcnet.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSD http://www.posi.net/freebsd/Team-FreeBSD/ 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?Pine.BSF.4.05.9911041647050.19966-100000>