easy way to determine if a stream or fd is seekable

[Stefan Esser]

Am 18.11.2011 06:00, schrieb perryh at pluto.rain.com:
> "Dieter BSD" <dieterbsd at engineer.com> wrote:
>> IIRC some tape drives can seek, while others cannot.
>> Vague memories that it is supposed to be possible to put a
>> filesystem on a DECtape and mount the filesystem.
> 
> Back in the Bell Labs 6th Edition days, it was possible to put
> a filesystem on a _9-track magtape_ and mount it, although such
> a mount had to be read-only since writing to a 9-track would
> effectively delete any blocks following the one written.
> I've done it.  Access was painfully slow (no surprise), but
> it did work.
> 
> DECtape _could_ be updated in place.  It was effectively the
> linear equivalent of a floppy disk (before floppy disks existed).
> Sequential access was slow.  Random access was very slow.

I dealt with quite a number of tape formats, long agao in a former
millennium, and still remember a few details ...

There used to be two types of tape: 9-track (and IIRC IBM3480/90) would
write variable size blocks separated by gaps, while most other formats
(QIC, DLT, Exabyte, DDS) used fix size sectors (some of them emulated
variable block sizes by using a variable number of sectors per logical
block with an interface similar to 9-track tape drives). These drives
used block headers to hold information about (emulated) block sizes and
to indicate file marks or EOT marks.

Linear read speed was in the range of 60KB/s (QIC-150) to 800KB/s to
1MB/s (9-track, Exabyte 8500c with compressible data), 3MB/s (IBM3480),
and 6MB (DLT8000). Very expensive high speed drives went to 60MB/s and
possibly beyond, but only when streaming large files.

While seeks are easy to implement for formats based on sectors (and e.g.
Exabyte offered "fast" seeks to sectors), each tape block may contain
any number of bytes on variable block size formats. This makes direct
seeks to byte offsets impossible, while it is still possible to skip any
number of block or file marks.

Seek times depended on the data layout on tape: linear (9-track, 3490),
serpentine (QIC, DLT), or helical scan (Exabtye, DDS). Linear and
helical scan tapes can skip to file marks at high speed by retracting
the R/W head or lifting the tape from the head (reduction of friction
and wear), while serpentine tapes just move the head to a height near
the target position (DLT drives have an index of file marks in a tape
lead-in block just for this purpose, which makes seeks to file marks
especially fast).

Due to the different hardware characteristics of tape formats, the
possible semantics of seek are different. And then there is the question
of how to deal with file marks (i.e. whether seeks end at a file mark,
as if the end of media had been encountered, or whether the seek
proceeds after the file mark, possibly to end of tape). Some tape drives
supported reading/seeking to a specific block and switching to write
mode without any gap. There was different behavior with regard to file
and EOT marks, e.g. whether a skip to filemark stopped before or after a
file mark.

All these differences made it hard to deal with seek/skip semantics in
the kernel, and only a few operating systems had proprietary code to
fully control the vendors drives (IBM, DEC). All others just made the
low level functionality available to applications, e.g. via ioctl(), and
let the application (e.g. backup software) implement support for all the
different tape drive behaviors (especially important for fast restore of
specific data from tape).

I have no idea, whether tape drives are still in wide use. For the
purposes that I administrated and used tapes for (gamma/particle
coincidence spectroscopy and large numerical simulations), large disk
arrays have completely replaced tape storage. Disk drives are cheaper
than tape cartridges, today ...

Regards, STefan