25

I'm in the market for a new storage solution. While researching various specs one of my coworkers said that some raid controllers can synchronize HDD rotation to the effect of all drives' sector/block 0 passes under the reading head at the same time.

I searched online but have not been able to find information proving/disproving this claim.

Mxx
  • 2,312
  • 2
  • 26
  • 40
  • Put an SSD and a spinning disk onto any RAID controller to disprove his theory, if voretaq7's answer isn't convincing enough. Or, for that matter, spinning disks of different RPMs. – HopelessN00b Sep 25 '12 at 16:34
  • 3
    @HopelessN00b Actually not that long ago it was a common requirement of RAID controllers that the disks in a RAID group all have the same spindle speed (because mixing different spindle speeds really does create performance problems unless the controller is smart enough to know about it and map locations appropriately: your writes suffer from the equivalent of [beat frequency interference](http://en.wikipedia.org/wiki/Beat_(acoustics))) – voretaq7 Sep 25 '12 at 16:41
  • @HopelessN00b Voretaq7 is right. In the really olden days (>25 years) this was even more important as the large, heavy motors/platters in use at the time would could create really bad resonant vibrations if things didn't match exactly. Up to the point of doing damage to disks. Sort of negates the purpose of a raid altogether :-) – Tonny Sep 25 '12 at 17:38

4 Answers4

28

Generally I'm pretty sure the answer is no (in fact I know of no controller that does this).

Doing such a synchronization would be incredibly difficult - vibration, temperature, natural power supply fluctuation, etc. all have small effects on the platter rotational speed (and if you want to be REALLY picky, the size of a sector). You would need to constantly vary the speed of the disk spindle motor by infinitesimal amounts to maintain synchronization, which would require very precise (very expensive) motor controls, and lots of disk controller overhead to determine the current platter position of each drive. As there's little to no practical benefit from doing this it's not worth the silicon and time.

(This idea also completely falls apart if you think outside the box of rotating rust media -- Solid State Disks have no seek time or spindle speed: Reads are effectively constant time for any sector, and there's nothing to "synchronize".)

voretaq7
  • 79,345
  • 17
  • 128
  • 213
  • 7
    Correct, this used to happen 10-15 years ago via a specific parallel SCSI sync command but it's virtually impossible to maintain these days with faster spin speeds and soft sectoring. – Chopper3 Sep 25 '12 at 16:48
  • 6
    @Chopper3 Good God - I forgot about [SCSI spindle sync](http://www.datapro.net/techinfo/scsi_faq.html#_Hlk410548006)! – voretaq7 Sep 25 '12 at 16:53
  • @Chopper3 I think that was more than 10-15 ago... But yeah, nothing does that these days because drives are so much faster and there'd be no benefit. – Chris S Sep 25 '12 at 17:00
  • Interesting..so perhaps he was right after all..based on an ancient information. :) – Mxx Sep 25 '12 at 17:34
  • I haven't seen spindle sync implemented since at least 15 years. Command does still exist in the SCSI (and SATA, SSA and SAS) specs, but it is a NO-OP just retained for backwards compatibility as far as I know. – Tonny Sep 25 '12 at 17:40
  • 2
    I had owned a Seagate ST410800n SCSI Drive (9GB, 5,25 inch full heigt), this drive had a special connector to make a spindle sync across different ST410800n drives. – Sunzi Sep 25 '12 at 20:08
  • Do you mean that an ordinary mechanical drive doesn't need to control the spindle speed?!? It does. In fact, the drive must have all the electronics to detect the speed and correct it, or the data would not be readable. It is actually not that much that is missing from getting all the drives synchronized: They need a common clock to synchronize to. – some Sep 26 '12 at 02:36
  • @some The spindle speed is significant as you say, and it is monitored, but the tolerance is relatively wide - a 15K RPM drive could easily be ±100 RPM or more depending on the variables I listed above (and more). In a perfect system you're right: All you need is a common clock to sync the spindles, but if you're trying to synchronize spindles with these real-world variables it's a nontrivial workload for the controllers (probably a [PID](http://en.wikipedia.org/wiki/PID_controller) circuit at a minimum...) – voretaq7 Sep 26 '12 at 05:32
24

RAID controllers did not (and could not) synchronize disk spindles, but it was an option on some drives. Given a set of identical drives with spindle sync connectors you could ensure a set of disks were all synchronized. I happened to own some Seagate Elite 3 (ancient, obsolete SCSI-2 drives) which I remembered having such a connector so I found the Seagate ST43400N/ND Elite 3 user guide which has this handy illustration in Figure 1 (note connector second from the left):

Seagate ST43400 illustration

Figure 14 (not shown here) illustrates how to connect the drives together:

Synchronizing the spindle

The spindle sync feature makes it possible to synchronize the spindle rotation of a group of disc drives. This reduces the latency normally encountered when the initiator switches between multiple disc drives. Figure 14 shows two system configurations. In one type of system, one of the disc drives in the system provides the reference clock. In the other type, an external signal source provides the reference clock.

Ben Jackson
  • 438
  • 3
  • 7
11

Synched drives dont make sense any more for several reasons:

  • Disks have bad sectors relocated at production. Disks are huge, and have a number of defects after production, which are relocated. Therefore, two disks of the same production run will not be 100% in sync anyway.
  • Disks internally relocate bad sectors during use. These sectors get moved to reserved space on the disk, putting it more out of sync.
  • Cache, TCQ/NCQ and relocated sectors make disk access ordering nondeterministic on the physical level. If the load is high, if one disk goes out of order, it may be a long time until it gets back in order.
  • Multi-Stripe access can go over sector (or even platter) boundaries, disaligning reads anyway. If you access, say, 4x stripesize on a Raid 6, some of the stripes might be in different zones of the different disks.
  • Read accesses in Raids generally do not target all disks, as long as the disks do not complain about their block checksum. This puts disks out of cache sync, and out of physical sync in consequence. (Unless you also turn off read cache)
  • Read caches on the raid controller, read-write caches in the OS further complicate the matter. And I hope there is no swap space on the raid, which might thrash any performance issues anyways.

In the early days, disk synch was implemented to make access deterministic, which was important when Memory to store results was scarce, or when the implementation of the raid needed it (Raid 2, Raid 3).

It is hard to quantify the advantages of synched drives. I suppose if there was a substantial performance advantage to be gained, synch would be possible in some way.

In the future, with SSDs, the matters are similar, but for different reasons, with block relocation, wear levelling, trim, etc.

Modern drives have their own operating systems and spend time internally for a number of issues, be it HD or SSD. Even if you made them physically in sync, logically they would not be in sync anyway.

3molo
  • 4,340
  • 5
  • 30
  • 46
Posipiet
  • 1,725
  • 14
  • 13
7

If you ever go down and use the never used RAID-2 where data is striped at the bit level, it required disks to be synched. No one I know ever used it, but, technically, if a RAID controller supports RAID2, it would need to be able to synch platter rotation. This would be the only need to have it now a days.

Rex
  • 7,815
  • 3
  • 28
  • 44
  • 1
    I have seen that once some 25 years ago. It required special drive-firmware with made the drives incompatible for normal SCSI operation. Quantum drives, 1GB if memory serves. We bought 2 of these drives in 1988 not knowing they had the special firmware. (The joys of "grey" markets and parallel imports. No wonder they were cheap.) Luckily the firmware was in a socket-ed EPROM which we could easily remove and reprogram with the normal firmware. – Tonny Sep 25 '12 at 17:48