Date: Wed, 11 Nov 1998 14:25:04 -0800 From: Mike Smith <mike@smith.net.au> To: Tony Overfield <tony@dell.com> Cc: Terry Lambert <tlambert@primenet.com>, hackers@FreeBSD.ORG Subject: Re: disk sector ordering (Was: Reading/writing /usr/ports is VERY slow) Message-ID: <199811112225.OAA05644@dingo.cdrom.com> In-Reply-To: Your message of "Wed, 11 Nov 1998 00:25:42 CST." <3.0.3.32.19981111002542.00752be4@bugs.us.dell.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Thu, 3 Sep 1998 01:08:15 +0000 (GMT), Terry Lambert said: > >Specifically, most modern disks record tracks in reverse sector > >order, and as soon as you seek to the track, they start reading > >(and buffering data) until they hit the sector in the track that > >you were actually seeking to find. > > Sorry about taking the side-track with such an old message, but > I've been trying to figure out what you said here and I just don't > get it. Can you explain this? Is there some reason you want to > avoid the concurrency you normally achieve by having the sectors > in the normal order? The goal here is to minimise time-on-track while optimising the cache contents once you leave the track. The expectation is that read behaviour is generally forward sequential - that one request for a region will be followed at some stage by a request for a region immediately following the first. This request may not come immediately, however, but it will generally come soon (and this is the only case easy to optimise for). So if you have a request for blocks 4-7 on a track, and when you get to the track you're passing block 14, you read 13 down to 4 and park them in the cache. You've gotten the blocks you want as quickly as possible, and as a benefit you've also cached 8-13 without losing any time. If the read is immediately followed by a request for 8-13, you don't have to wait a whole rotation as they're already in the cache. (If the sectors were ordered forwards, by the time you'd transferred 4-7 to the host you would be out of luck for 8-11.) You can also win in this case if you simply read ahead. If the request is followed by a request for another region of the disk, you can go straight there, improving your response time. And if *that* request is then followed by the request for 8-11, you can still satisfy it from the cache. If you were only doing read-ahead, you would have aborted the read-ahead as soon as the next transaction arrived. On average, you can expect to get a free half-track readahead simply by reversing the order of sectors on the disk. What used to be dead time (waiting for the target sector to appear) is no longer wasted. I hope that helps... -- \\ 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-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811112225.OAA05644>