Re: Raid
From: Steve Foster [SBS MVP] (steve.foster_at_picamar.co.uk)
Date: 06/19/04
- Next message: SuperGumby [SBS MVP]: "Re: Dcpromo"
- Previous message: Kevin Weilbacher [SBS-MVP]: "Re: remote users"
- In reply to: root: "Re: Raid"
- Next in thread: root: "Re: Raid"
- Reply: root: "Re: Raid"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 18 Jun 2004 21:20:35 -0700
root wrote:
> > > Do you actually know anything about how RAID 5 works?
> >
> > Do you?
>
> Obviously!
How so, since you've not yet presented any evidence that you do, nor
cited any references for your claims. You've turned up in this group
over the last few months, antagonised a significant number of posters
with rude comments and troll-like behaviour, and generally been one of
the most disruptive and unhelpful elements this group has seen in a
long time. You have exhibited a clear lack of knowledge with the SBS
product, and yet have been reluctant to accept just about any answers
you've been given, demanding that posters present references to back up
their comments and positions, however you refuse to reciprocate when
others ask you for references or cites.
>
> > > > Bear in mind that in RAID1, two read requests can be satisfied
> > > > simultaneously by applying one to each half of the mirror.
> > >
> > > Right.
> > >
> > > > RAID5 cannot
> > > > do that - each request must be satisfied in turn.
> > >
> > > Flat WRONG. RAID 5 could have an independent read going on EACH
> > > drive in the array simultaneously and under load WILL.
> >
> > Ahem, in RAID 5, each block of data is spread across multiple
> > drives,
>
> 'Block'....what's a block in this context? Do you know the difference
> between blocked RAID 5 and striped RAID 5? Do you know the difference
> between a cluster, a stripe and a stripe unit? What entity exactly
> do you believe is "spread across multiple drives" ?
A block in this context is the smallest atomic unit of data that the
array writes with parity information. Let's make it really simple, and
assume that block size is 1 byte (silly but workable) plus parity. Now
if an OS writes 1 byte to a RAID5 array, that one byte will have parity
information calculcated and added, and then the byte + parity will be
chopped up into equal portions and written across the members of the
array. Let's assume a 5 drive array and that the parity information
will add 2 bits to each byte. So for any byte an OS writes, 10 bits
will actually be written to the array. bits 1 and 2 go on drive 1, bits
3 and 4 on drive 2, and so on.
Obviously, the encoding scheme is a bit more complicated than this (eg
the data is normally "staggered" to avoid all the parity data landing
up on one drive), but that's the basic idea.
Now when you want to read that byte back, since it's divided evenly
across all the array members, you need to read from all the members
(well, all bar 1 to be picky) to reconstruct it.
Suppose the block size was 4k, then that 4k + parity data is divided
among the members of the RAID5 array and a portion written to each
drive. To reconstitute the 4K, you need to read all the drives.
If you disagree, please go right ahead and give us your explanation
(and try to keep the explanation simple enough for those of us with
brains and egos smaller than yours).
>
> > so to complete any read request on RAID5, all drives must be read
> > together.
>
> That's flat false whether blocked or striped .
>
> A striped RAID 5 read is basically the same as a RAID 0 read.
Well, if it's a true striped RAID0 (rather than just N drives logically
"stuck together"), then any block of data (of whatever size the
array/OS chooses) is divided into N pieces (where N is the number of
drives in the array) and written one portion per drive. So, for
example, if the block size were bytes and it was a 2 drive array, bits
1-4 would be on drive 1, and bits 5-8 would be on drive 2.
> > > > However, in situations where the data requested is all
> > > > contiguous and in large quantities, a RAID5 array probably
> > > > would beat a RAID1 mirror, even with just 3 drives.
> > >
> > > Well, >3 drive RAID 5 will be faster that 2 drive RAID 1 in small
> > > record random I/O situations as well.
> >
> > No, because the read requests must be queued on RAID5, where they
> > can be executed in parallel on RAID1.
>
> That's flat false. All drives in a RAID 5 array may be doing
> independent I/Os simultaneously. Both cases allow 'parallel'
> operation. In a busy(saturated) SCSI RAID 5 array each drive WILL
> have MANY I/Os queued onboard each drive simultaneously. They get
> there because the device driver, OS and RAID controller firmware all
> know the array can be fed many I/Os before the first one finishes.
> Study up on the concept of HD 'command queuing' and how it's
> exploited in RAID 5 arrays.
I don't disagree that you can submit many I/O requests to a RAID array
without a single one completing, but none of those requests can be
satisfied without a physical read request being completed on each array
member. Unless you're telling us that RAID5 doesn't really spread data
across all the drives? And what the RAID manufacturers have been
telling us all is garbage.
-- Steve Foster [SBS MVP] --------------------------------------- MVPs do not work for Microsoft. Please reply only to the newsgroups.
- Next message: SuperGumby [SBS MVP]: "Re: Dcpromo"
- Previous message: Kevin Weilbacher [SBS-MVP]: "Re: remote users"
- In reply to: root: "Re: Raid"
- Next in thread: root: "Re: Raid"
- Reply: root: "Re: Raid"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
