I think for the puropose of this disucussion we should assume a type of
files. (large contiguous, versus smaller un-contiguous) The way the data
is access differes on the type of files as well. If you are using
hardware RAID, this is true with most raid devices. Even in a SAN, wher
you might have several disk trays and say 2 controllers, or a single
head-unit with 2 controllers enclosed using either FCAL or FABRIC.
Most read-ahead on RAID devices are adaptive by default, unless you're
tweaking it. Also, in the case of something like RAID3, you'll have
pretty stellar performance if you're using those large contiguous files,
versus if you tried to use smaller contiguous or un-contiguous files,
your overall performance would dump out.
On Wed, 2002-04-24 at 10:24, Greg Freemyer wrote:
> >> Plus, once you are on a raid device,
> >> logical and physical closeness on the volume no longer mean very
> much.
>
> Don't they?
>
> I would have thought:
>
> Raid 0: physical distance = logical distance / spindles
> Raid 1: physical distance = logical distance
> Raid 1 + 0: physical distance = logical distance / spindles / 2
> Raid 5: physical distance = logical distance / (spindles - 1)
>
> Certainly caches and elevator seeks can come into play, but it still
> seems worth considering the physical distance.
>
> The only array I know of that would not work basically like the above is
> Compaq's really high-end EVA system.
>
> I'm sure there are others, but I have to believe the vast majority of
> arrays use a very simple block layout.
>
> Greg Freemyer
> Internet Engineer
> Deployment and Integration Specialist
> Compaq ASE - Tru64
> Compaq Master ASE - SAN Architect
> The Norcross Group
> www.NorcrossGroup.com
>
--
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-698-7250
email: austin@xxxxxxxxxxxxxxx
"It is the part of a good shepherd to shear his flock, not to skin it."
Latin Proverb
signature.asc
Description: This is a digitally signed message part
|