buffered vs. raw floppy disk device access

[Brad Rosser]

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 at griffin.itc.gu.edu.au