Date: Tue, 15 Sep 1998 15:52:56 -0500 (CDT) From: Joel Ray Holveck <joelh@gnu.org> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: joelh@gnu.org, 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: <199809152052.PAA13120@detlev.UUCP> In-Reply-To: <27308.905841833@critter.freebsd.dk> References: <27308.905841833@critter.freebsd.dk>
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. 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? Best, joelh -- Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped 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?199809152052.PAA13120>