> On Sep 28, 2017, at 9:04 AM, Jon Elson via cctalk <cctalk@classiccmp.org> > wrote: > > On 09/28/2017 10:31 AM, Chuck Guzis via cctalk wrote: >> And even the sector size on recent drives is fictitious. Larger drives use >> 4K sectors but "translate" them to the 512 byte standard. > So, for every write, it needs to read the 4K sector, alter the bytes and then > rewrite it? Hmmm, explains why writes are slower than reads even on spinning > disks. Of course, if you write entire tracks, it can just hold the partial > data until it has all the data for that track, and write out the buffer in > one rotation.
Given that many drives have megabytes of “cache” it’s not really an issue. There is *a lot* of buffering going on in drives. Generally drives now-a-days will read an entire track at a time. They don’t even wait for the index (sector 0), they start reading at the first sector and fill in the buffer as the sectors come under the head. Rotational latency still shows up at the interface if you’re wanting a *specific* sector, you have to wait for it to be read but generally the drive will read the entire track so the next sector will be just uCode latency for the command and the transfer time over the interface. Writing is a bit more of a challenge (because you *do* want the data to make it to the surface) but in general they are buffered also and there’s some interesting stuff going on in the drive to make sure that all of the data is written properly. TTFN - Guy
