MikeHalloran, I followed paragraph 1 fine. I think I might have gotten lost in the 2nd, because it seemed to be talking about delays in all drive technologies. For example, I assumed ALL drives went open loop in the gross movement from initial track to destination track and closed loop aligning the head precisely over the track.
IRstuff, you are right about fragmented files, but there are very few fragmented files. This computer I am using right now reports 2. I estimate there are actually 0-20 more based on failing sectors being remapped at a low level. And anyway, spiral and conventional are penalized about equally for any track change. And re spiral position, in my original post I mentioned I thought one would need to “add a sensor to track the platter(s) angle”. Doesn't that plus the head location let me know where on the spiral I am?
I laid out how I understand the current architecture works and how I imagine a spiral sector architecture would work for comparison.
0) Initial state. Head is over a random track. Ignoring multiple platters and heads. Ignoring sector size. Sectors per track is fixed at 64 (0-63). I don't believe this setup gives an advantage to either data organization architecture, and allows me to simplify a bit.
Read using Track Sector Architecture
T1) Receive request for track 300,000 sector 3 through track 300,001 sector 5.
T2) ~6ms Calculation is done using current voice coil position and destination voice coil position. Head accelerated and decelerated to try for track 300,000.
T3) ~1ms (settling time) User data and servo data are read; voice coil is adjusted till we are within tolerance and can trust we know what sector we are reading and its value. If we are on the wrong track we could trivially go back to step 2.
T4) ~8ms (just shy of 1 revolution) Read 61 sectors while adjusting voice coil till we have sectors 3 through 63.
T5) ~0.5ms Head accelerated and decelerated to get over next track.
T6) ~0.5ms User data and servo data are read; voice coil is adjusted till we are within tolerance and can trust we know what sector we are reading and its value.
T7) ~2ms (say a quarter revolution) Read 6 sectors till we have 0 through 5. Since drive data is organized to minimize track-to-track latency, sectors we want are probably in the first few we read, so we don't need to wait for a full revolution.
T total 18ms
Read using Spiral Architecture
S1) Receive request for track 300,000 sector 3 through track 300,001 sector 5.
S2) ~6ms Calculation is done using current voice coil position and destination voice coil position and platter angle. Head accelerated and decelerated to try for spiral sector (300,000*64+3) – (estimate of number of settling time sectors).
S3) ~1ms (settling time) User data and servo data are read; voice coil is adjusted till we are within tolerance and can trust we know what sector we are reading and its value. If we are on the wrong track we could trivially go back to step 2.
S4) ~9ms (just over 1 revolution) Read 67 sectors while adjusting voice coil till we have them all.
(No need for steps 5-7)
S total 16ms
I'm not saying this is typical, it just demonstrates where the time savings the would come from and assigns some labels. For example, during S4, since the voice coil is being adjusted anyway, I assumed the head could be adjusted inward 1/64 of 1/300,000 of an inch per sector (at 300,000 tpi). That might not be true.