Quote:> i've been looking around various os's and the like [mostly
> bsd type] and have been trying to figure out why there
> is a block special device for tape drives.
On Auspex systems, the tape driver for tapes attached to a storage
processor does *NOT* support the block device interface; I had to floss
my cat that evening, so I didn't bother. :-)
I.e., I consider implementing a block device interface for tapes to be
less useful than, say, flossing one's cat. The block size provided by
the block device interface is usually rather small and, on
variable-block-size tapes, a small block size is often undesirable, as
more of the tape is wasted on inter-record gaps.
On top of that, it requires some kludges to let the system know that it
can't just do delayed writes on tapes, as they may not go out in the
same order in which they were requested, and requires that the device
driver be able to cope with seeks by checking the seek offset on I/O
Block device interfaces for tapes - Just Say No!
Quote:> almost all the commands i ever use only care about the raw
> devices [n]rst?, not the block special ones...
I'm not sure I can remember having used the block device interface to a
Quote:> is there something special about the tapes that makes them
> have to have similar device driver layout to disk drives,
> even though they function quite differently....?
No, it may have been a misguided attempt at device-independence, or a
desire to do read-only file systems on tapes, or something such as that.
(NOTE: DECtape doesn't count as "tape" in this context, as it's a
random-access rewritable device and intended to be used as such, so
"what about DECtape?" doesn't count as a good reason for supporting the
block interface on, say, 9-track tapes, or 8mm tapes.
Also, many *modern* UNIXes have "ioctl"s to let you position the tape,
so "how else would you be able to seek on a tape?" doesn't count as a
good reason, either.
Some tape drivers even attempted to support seeks-by-"lseek()" - or
maybe it was so long ago that they were seeks-by-"seek()"! - on the
raw device, but that's just Too Silly For Words, as you can't assume a
fixed block size for most tape devices.
And, no, "what about 1/4" tapes?" doesn't count as a good reason,
either, even though they do have a fixed block size.
In sort, the KISS principle applies here - Keep The Driver Simple,
Stupid, and don't do block devices or support of "lseek()".)