Date: Thu, 31 Aug 1995 13:10:34 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> To: terry@lambert.org (Terry Lambert) Cc: pete@kesa26.kesa.com, jbryant@argus.iadfw.net, freebsd-hackers@FreeBSD.ORG, pete@rahul.net Subject: Re: 4GB Drives Message-ID: <199508312010.NAA12388@gndrsh.aac.dev.com> In-Reply-To: <199508311707.KAA22925@phaeton.artisoft.com> from "Terry Lambert" at Aug 31, 95 10:07:21 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Now, can you all leave me alone for 30 days so I can go get the stripes > > working, I have small bottleneck that needs fixed :-):-):-) And can > > anyone tell me what the mean and standard deviation of an I/O request to > > an aic7870 is before it hits the drive given 0 scsi bus contention? This > > seems to greatly effect rotation offset on stripe sets when pushed to > > the limits of data coming under the head just after the I/O hits the > > drive. > > Modern drives write sectors in reverse order; when asked to read, they > start reading from where the head is at and keep reading until the sector > you want is read. For contiguous reads, this pre-caches the data. > > I think you would achieve an effect opposite of the one you want if you > were to successfully rotdelay. One more time you are totally out of context with this, that happens, let me explain what I was talking about when I said ``rotation offset''. You see, in modern workstation disk drives you have something called spindle sync. Well, when you set up spindle sync you have 2 modeselect values you tweak. One bit says who is the sync master and who are the sync slaves. Then for each slave drive you tweak another value that is used to offset the spindles from perfect sync so that the I/O of block zero of a track on drive 0 of a stripe set has just finished the scsi bus transfer when block zero of a track on drive 1 is about to come under the heads. I was in no way talking about ``rotdelay'' in the file system since, I am still playing with raw devices at the block level, no file systems have been built since the slice code kinda screwed me up for getting labels on the things. > > One thing that *would* speed you up is not crossing physical cylinder > boundries (seek scheduling ala the old BSD code). The problem with > this is that the information is only available from SCSI II devices > and is not linearly bound (ie: the track length varies by zone), making > it difficult to use without adding a lot of overhead. But it's probably > yor best bet. Already looking at those factors. I am given the fact that my drives will be SCSI-II, will report the zone pages, etc. Without that stripe sets are pretty stupid and can never be made to go fast. I have been able to get to 85% of theorotical bandwidth, not bad, but want to sqeeze that on up to 95% before I go looking at laying file systems on this thing. > Without the physical seek locations, any benchmarking will be rather > arbitrary based on the layout you end up with for a particular test. To eliminate this very problem whilst I work on the technological ends of things I am simply doing raw disk I/O starting at the same logical drive on all spindles. Those do often end up in the same physical location, and when I want the best numbers simply start at logical sector 0 which will always be physically the same location on all spindles sans whatever value I put into scsi mode page 4:Rotational Offset:. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508312010.NAA12388>