brad@griffin.itc.gu.edu.au (Brad Rosser) (04/14/91)
For the last few years as an SCO Xenix user I've had ingrained in me the notion that "raw is fast". Hence I've always written my shell scripts, etc, to access floppy disks as raw devices. Today I just took some measurements that prove how stupid I've been, and I'd like to find out from those-who-know why *buffered* floppy access is so much faster. My 24Mhz '386 AT system is running Xenix 2.3.2. It has a 40Mb MFM drive and a single 1.2Mb 5 1/4" floppy drive. It has 8Mb of memory, 2Mb of which is allocated for a /tmp ramdisk, and comes up with 800 auto-configured disk buffers. I've made the following measurements using dd. For example, for a raw write to floppy of a 1.2Mb disk image using a blocking factor of 10k: dd if=<disk file> of=/dev/rfd096ds15 bs=10k Read output was directed to /dev/null. Here's what I got (running multiuser, but with no other active "jobs" running): writes reads buffered (/dev/fd096ds15): 59s 42s raw @ 10k b' factor: 1:55 2:09 raw @ 1200k 2:01 2:06 Here's my guesses as to why buffered floppy access is so much faster. No big deal, it's all standard comp. sci - I'm just kicking myself for never having "realized" it for my own home setup! I'd appreciate comments on where I've gone wrong. Buffered writes are so much faster because: o with the kernel's buffering scheme in action it's effectively a 2-process "parallel" operation, with the dd process able to fill up buffers whilst the OS is emptying them; (vs. the "mono-process" raw scenario); o the buffered device driver is sorting sectors according to floppy disk interleave for the device; OR o it's "caching" entire tracks, and writing them out according to heuristics like o write when track full (?) o write when new track request made o write out at "close of device" (It's interesting to see the block device's buffers flushed after dd "thinks" it's finished ... for a full 10-20 seconds after dd's closing dialogue the floppy is still in action ... I assume the drive's close() function ensures that all dirty buffers are written before returning?) My guess is that buffered reads are so much faster due to the driver caching tracks or making "full track" buffered reads. So ... where have I gone wrong this time? For example, for the "writes" above, can a driver perform a "full" track" write to a floppy drive, or can one only present a sector at a time to a (dumb) controller? In which case, if the buffer queue is sorted, is a floppy disk slow enough such that the kernel's lower-half of the device driver can quite cheerfully grab the physically-next sector in the queue before the sector has passed by? For that matter, can a hard-disk driver? I've no idea of the relative times involved between cpu and hard/floppy disk drives. What other strategies are incorporated in floppy/hard-disk drivers that speed things up? Why is the raw @ 1200k several seconds slower than the 10k case for writes, but slightly faster for reads? dd idiosyncrasy? The full 1200k read in one blow slightly faster due to no stop/start in the middle of a track? Paging slows the dd write @ 1200k down? (I doubt this myself ...) In summary, for my own future use: I may have gotten this "raw is faster" notion from the principle of raw *mag tape* being faster. Is this (still) true? Would a process writing to tape be faster using a buffered device so some "parallel" processing can take place? (I remember reading, over the years, discussions in unix.wizards about clever "dump" strategies, presumably incorporating parallel processing in the dump program itself ... should I merely put my trust in a clever device driver instead? PS: I haven't had any exposure to BSD) I've (likewise) always assumed that one should use raw devices for disk partitions/databases, etc, under xenix, ie dd if=/dev/rdisk2 of=/dev/rct0, etc. Am I wrong here also? Any and all help/advice/comments/lectures would be welcome! ------------------------------------ Bradley Rosser brad@griffin.itc.gu.edu.au