[Cryptography] cheap sources of entropy

Jerry Leichter leichter at lrw.com
Sat Feb 1 23:47:34 EST 2014

On Feb 1, 2014, at 11:02 PM, James A. Donald wrote:
> ...Disk read completes at a time that depends on disk turbulence.  The real machine now has to do something with the data.  Letting it pile up to the next scheduling quantum is going to result in the disk head passing over the next disk sector, resulting in a painfully slow read.  So, unless your real machine is crazy inefficient, it is going to immediately wake the consumer of the data at a time that depends on disk turbulence, in the hope that it can read sectors sequentially as the platter spins.
Your model of how modern disks work is way out of date.  To take one very simple example, the notion of missing a block because the sector has already passed under the head hasn't happened in years.  Disk firmware buffers entire tracks.  If you need sectors n through n+k on a track, the disk firmware will start filling the track buffer as soon as any sector in the range is available, and continue as long as the head is over sectors in that range.  Then, depending on where it started, it will do that again starting and sector n.  (Actually, for simplicity it may well just buffer the entire track on the theory that there is likely to be another read from the same track "soon", and the data is moving under the head anyway.  There's plenty of RAM in a modern disk drive to buffer several tracks.)

Virtualization would be impractical if the hypervisor had to worry about scheduling VM's fast enough to pick off individual disk sectors.

Beyond this ... you're not even going to *see* the real disk.  That data will be delivered over fiber channel emulating a LUN, or (probably the majority of the time these days) over an Ethernet, either emulating FC protocols or running iSCSI or even NFS.  Oh, if you're using an FC-like or iSCSI-based disk, you might send a "read sectors n to n+k" command, but that's going to be interpreted by some fairly high-level code in the disk server, and it's likely to look quite different by the time it hits the actual disk - and by the time the data wends its way back to the requesting machine.  To take an extreme example:  NetApp, the second-largest supplier of disk arrays, started out building NFS servers, then added support for block I/O to virtual disks later.  What you see as a "disk" is actually a file in a file system (WAFL) that was designed to support NFS efficiently.  (The biggest maker, EMC, took the opposite approach, initially selling block servers, then later building an NFS server that layered over the block server.)

                                                        -- Jerry

More information about the cryptography mailing list