Date: Wed, 2 Feb 2000 11:27:55 +1030 From: Greg Lehey <grog@lemis.com> To: "Justin T. Gibbs" <gibbs@FreeBSD.org> Cc: "Justin T. Gibbs" <gibbs@plutotech.com>, Gary Palmer <gjp@in-addr.com>, scsi@FreeBSD.org, up@3.am, Wilko Bulte <wilko@yedi.iaf.nl> Subject: Re: hardware vs software stripping Message-ID: <20000202112755.L55303@freebie.lemis.com> In-Reply-To: <200002012221.PAA62239@caspian.plutotech.com> References: <20000202082214.S76348@freebie.lemis.com> <200002012221.PAA62239@caspian.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, 1 February 2000 at 15:21:04 -0700, Justin T. Gibbs wrote: >> That doesn't correspond to any of the definitions I have seen. Where >> did you get it from? > > This is from the RAID Advisory board's RAID book. Take a look at > www.raid-advisory.com for ordering details. Hmm. That's cheaper than I remember it. I thought it was in the order of $500. I suppose I should order it. > Here's what the RAID Advisory's RAID book has to say: > > RAID Level 3 > > Raid Level 3 adds redundant information in the form of parity to a parallel > access striped array, permitting regeneration and rebuilding in the event > of a disk failure. One "strip" of parity protects corresponding strips of > data on the remaining disks. Raid Level 3 provides high data transfer > rate and high data availability, at an inherently lower cost than mirroring. > Its transaction performance is poor, however, because all RAID Level 3 array > member disks operate in lockstep. > > RAID Level 4 > > Like RAID Level 3, RAID Level 4 uses parity concentrated on a single disk > to protect data. Unlike RAID Level 3, however, a RAID Level 4 array's > member disks are independently accessible. Its performance is therefore > more suited to transaction I/O than large file transfers. Raid Level 4 is > seldom implemented without accompanying technology, such as a write-back > cache, because the dedicated parity disk represents an inherent write > bottleneck. Is this all they say about it? It begs the question why RAID-3 must access all members of the disk at a time. The only reason I can think of is that the data is interleaved in such a manner that you can't get *any* useful data without reading them all. This rather agrees with the idea that the data is spread in units of less than a sector. It also doesn't say why RAID-4 is less suitable for large file transfers. My understanding is that RAID-3, effectively striping at a sub-sector level, can give much higher data rates without buffering, and that's its raison d'être. >>> In RAID4, it is supposed to be a multiple of your transaction size >> >> Where do you get the term "transaction" from? I haven't seen it in > > From the dictionary? 8-) > > The point is that your system is such that you may be able to > satisfy a request by only reading one component of the stripe. That's one point. My point is that a transaction may be of various sizes, whereas the stripe has a fixed size. >> any RAID documentation. In ufs, there is no fixed size. > > Sure there is, the block size (i.e. 8k.) ufs has a block size, sure, but the transfers are very seldom equal to the block size. > But then again, you wouldn't usually use RAID 3 or 4 for a > filesystem. Agreed. I wouldn't use RAID-4 for anything. >>> and RMW operations to update the parity for updating contiguous >>> transactions that are not as large as the stripe. >> >> I'd call both of these RAID-4, considering that RAID doesn't use the >> term "transaction". > > Sure it does. Is this in The Book as well? How is it defined? > In RAID-3, your transaction size *is* the stripe size. In RAID-4, > it may be less than the stripe size. So what is it in the Pluto implementation that stops you from reading only part of a RAID-3 stripe? Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000202112755.L55303>