Date: Tue, 15 Sep 1998 15:58:51 -0700 From: Mike Smith <mike@smith.net.au> To: joelh@gnu.org Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Terry Lambert <tlambert@primenet.com>, tom@uniserve.com, gpalmer@FreeBSD.ORG, irc@cooltime.simplenet.com, freebsd-current@FreeBSD.ORG Subject: Re: Download of FreeBSD 3.0-SNAP Message-ID: <199809152258.PAA01641@dingo.cdrom.com> In-Reply-To: Your message of "Tue, 15 Sep 1998 15:52:56 CDT." <199809152052.PAA13120@detlev.UUCP>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Well, this is almost still the case. Most modern disks lay out the > > sectors in a track backwards, they start reading as soon as they > > hit the track and cache all they get. That means that if you ask > > for sector 5, there is a good likelyhood that 6, 7, 8... is already > > in the cache when you ask for them a moment later. > > Do you mean that if a cylinder has blocks 100 thru 163, then it may > start reading at block 130, and then cache 130-100 followed by > 131-163, or does it only read ahead (130 thru 163)? Either way, it > would seem that deviating slightly from an elevator sort would mean > possibly one less track to seek to later. It varies depending on the drive. You can assume that if it has a request for block 100, and when it gets to the track it's over block 130, it will read 130-100 into its cache. It may or may not then proceed to read 163-131 in, depending on eg. whether it gets another request, its current policy, etc. > Without knowing the true geometry of the disk (which I assume EIDE > doesn't allow), we can't optimize for the cylinder patterns anyway, so > I suppose it's a moot issue. I suppose that by manually specifying > the geometry at format time then it could be slightly optimized for > those hdd's that come with true geometry. Was that taken out because > the computation was outweighing the seek time benefits, or what? Disk geometry is nonlinear, and the calculations involved in optimising for it are complex and not really compatible with the optimisations for this sort of thing already part of the filesystem. (You would have to prevent filesystems from crossing zone boundaries, eg.) There's no such thing as "true geometry" anymore. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809152258.PAA01641>