Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!mitel!sce!cognos!geovision!gd
From: gd@geovision.uucp (Gord Deinstadt)
Newsgroups: comp.arch
Subject: Re: 64-bit addresses
Summary: disk farms not synchronized
Keywords: disk farm
Message-ID: <787@geovision.UUCP>
Date: 21 Feb 90 04:56:08 GMT
References: <9708@spool.cs.wisc.edu> <20270@cfctech.cfc.com> <131646@sun.Eng.Sun.COM> <8275@cbnewsh.ATT.COM>
Reply-To: gd@geovision.UUCP (Gord Deinstadt)
Organization: GeoVision Corp, Ottawa, Canada
Lines: 25

In article <8275@cbnewsh.ATT.COM> dwc@cbnewsh.ATT.COM (Malaclypse the Elder) writes:
 
>i'm not a 'disk farmer' but with a certain amount of redundancy,
>the read of the first byte can be improved.  in the simplest case,
>if the byte is on two separate disks, then all you have to do is
>wait for the FIRST one to come.  what this does is decrease the
>expected seek and latency times which is the major component of
>of the delay to get the first byte.  and if you explicitly place
>that byte of 'opposite ends' of the two disks, then you have decreased
>the minimum and maximum delay.

From what I have read, I have the impression that the various disks in
the farm are NOT synchronized with each other.  They are just a bunch of
off the shelf drives, so they each rotate independently at their own
rate.  So, even if the blocks were opposite when written, they wouldn't
likely be later.

You could still do it within a single drive, though; just write the data
twice.  You would get a certain amount of fault tolerance, too, though
not as much as a real disk mirror.  Does anybody do this?

Ahhh, probably not... they'd only gain on the rotational latency
anyways, and seek time dominates.
--
Gord Deinstadt   gdeinstadt@geovision.UUCP