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

To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message