tapes as block devices?

tapes as block devices?

Post by Marc WANDSCHNEID » Tue, 18 Jan 1994 07:33:45



mooo!

        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.

        almost all the commands i ever use only care about the raw
        devices [n]rst?, not the block special ones...

        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....?

                                                marc 'em.
--
-----------------------------------------------------------------------------
Marc Wandschneider                                          Seattle, WA
Barney the Dinosaur sings! You faint... Barney sings!  Barney sings! --More--
You Die... --More--

 
 
 

tapes as block devices?

Post by Guy Harr » Tue, 18 Jan 1994 10:28:51


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.

Good question.

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
operations.

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
tape.

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()".)

 
 
 

tapes as block devices?

Post by John Hasca » Tue, 18 Jan 1994 23:33:50



}>   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.
}Good question.
}I.e., I consider implementing a block device interface for tapes to be
}less useful than, say, flossing one's cat.   ...
}Block device interfaces for tapes - Just Say No! ...
}In sort, the KISS principle applies here - Keep The Driver Simple,
}Stupid, and don't do block devices or support of "lseek()".)

When reading certain kinds of tapes created by bletcherous old
IBM dinosaurs it is important to know where the block boundaries are
on the tape -- whether this means using a block-mode interface, I dunno...

John
--
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551

 
 
 

tapes as block devices?

Post by Romain Ka » Wed, 19 Jan 1994 03:07:03


Actually, Pyramid OSx (the pre-MIPS OS) is still distributed to boot
from a mini-root on tape, i.e., the block device.  I suspect the reason
for this was because it seemed like a neat hack.  It had the added
benefit that you didn't need lots of memory for a RAM-based mini-root
-- this was 1985 -- and you didn't have to depend on anything from a
possibly zorched system disk  -- 1985 again, and configurations with a
single 400 MB Fujitsu Eagle were common.  If necessary, the disk could
be reformatted, which is not true of mini-roots in swap partitions.

The mini-root was assembled on a disk partition, with mkfs parameters
frobbed to make plain files use contiguous blocks; the result was dd'd
to the distribution tape.  To make life simple, the mini-root was
mounted read-only.  It was necessary to run a few commands to make sure
that the commands and critical device nodes were in the buffer cache
before forwarding the tape to the root cpio archive.  Systems with 1MB
of RAM couldn't pull this off because their buffer caches couldn't be
made large enough without sacrificing too much program memory.

For those who are still reading and curious, the current Pyramid OS
(DC/OSx) is booted from scratch by using a stand-alone shell to copy
the mini-root from tape into RAM.

 
 
 

tapes as block devices?

Post by Peter Van E » Wed, 19 Jan 1994 01:52:24




>}>       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.
>}Good question.
>}I.e., I consider implementing a block device interface for tapes to be
>}less useful than, say, flossing one's cat.   ...
>}Block device interfaces for tapes - Just Say No! ...
>}In sort, the KISS principle applies here - Keep The Driver Simple,
>}Stupid, and don't do block devices or support of "lseek()".)
>When reading certain kinds of tapes created by bletcherous old
>IBM dinosaurs it is important to know where the block boundaries are
>on the tape -- whether this means using a block-mode interface, I dunno...
>John
>--
>John Hascall                   ``An ill-chosen word is the fool's messenger.''
>Systems Software Engineer
>Project Vincent
>Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551

Shouldn't. The exciting part here is interpreting the 11 million different
tape formats that an IBM can crank out. In the conversion from our mainframe
to Unix we had to be able to read some funny IBM formats. While we used a
VAX to do the reading of the tapes, it does just give us a raw stream of
bytes from the tape which a C program then interprets, and I did the prototype
on 1/4 inch Carts (using an AIX/370 system at another site to get the data
onto the cart) to demonstrate it was possible (and that used the raw device).
Reading IBM standard label tapes used to take three different programs on the
VAX to cover all  of the formats that we standardly receive (the data is then
passed to the Auspex file server via FTP). While this is partly because the
3420 and 3480 tape drives already exist on the VAX, it is also partly because
we have not found Unix code that will read the various IBM formats. There was
some talk about a group of the MTS sites doing our own (since it had been done
for MTS) but so far I haven't seen anything come of that.

Peter Van Epp / Operations and Technical Support
Simon Fraser University, Burnaby, B.C. Canada

 
 
 

tapes as block devices?

Post by Leo Broukh » Wed, 19 Jan 1994 07:44:43



>    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.

>    almost all the commands i ever use only care about the raw
>    devices [n]rst?, not the block special ones...

>    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....?

        Didn't you ever want to mount a tape with (uncompressed)
dump of a filesystem? Read-only, of course, but it's still useful
if your tape driver supports it.
--
        Leonid A. Broukhis  | Misce, Da, Signa: After each e-mail message.
 
 
 

tapes as block devices?

Post by Guy Harr » Wed, 19 Jan 1994 17:49:17


Quote:>    Didn't you ever want to mount a tape with (uncompressed)
>dump of a filesystem?

Nope.  Life's too short for that.
 
 
 

tapes as block devices?

Post by Guy Harr » Wed, 19 Jan 1994 17:55:50


Quote:>When reading certain kinds of tapes created by bletcherous old
>IBM dinosaurs it is important to know where the block boundaries are
>on the tape -- whether this means using a block-mode interface, I dunno...

No, it means using the *character* device.

If you try to read, say, 32768 bytes from the block device for a tape,
it'll try to read 32768/N N-byte blocks, where "N" is the block size
used for block device reads on your system.  If the blocks aren't N
bytes long, this may not work (probably won't work if they're *longer*
than N bytes long).

If you try to read 32768 bytes from the *character* device (the raw
device) for a tape, it'll try to read one 32768-byte block (unless the
OS breaks up reads that big into smaller blocks because it thinks the
tape controller or some other piece of the system can't handle blocks
that big, but if there's e.g.  a "minphys"-style limit, it's more likely
to be 64K, or maybe higher).  If the block is smaller than that, it
should read in only the number of bytes in the block, and "read()"
should return the actual number of bytes in the block.

 
 
 

tapes as block devices?

Post by Benjamin Z. Goldste » Fri, 21 Jan 1994 08:17:58




>>        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.

>>        almost all the commands i ever use only care about the raw
>>        devices [n]rst?, not the block special ones...

>>        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....?
>    Didn't you ever want to mount a tape with (uncompressed)
>dump of a filesystem? Read-only, of course, but it's still useful
>if your tape driver supports it.

     I wish the UNIX's I used supported it -- read/write too.  VMS supports
it afterall (though I have been told it is not recommended...slow as a dog
certainly).  Why should I have to use tar(1), or dump(1M) to work with files
the way I usually do (mt(1M) and dd(1) or simple redirection to work the
binary of the files)?  I want the file system damn it!

Thank you for letting me get that off my chest!
--
Benjamin Z. Golds*

 
 
 

tapes as block devices?

Post by Guy Harr » Fri, 21 Jan 1994 10:11:37


Quote:>     I wish the UNIX's I used supported it -- read/write too.  VMS supports
>it afterall (though I have been told it is not recommended...slow as a dog
>certainly).

Does VMS support mounting a mag tape with an image dump of a Files-11
on-disk file system, or does it just support mounting a file-structured
tape that uses ANSI standard labels to delimit files? (NOTE: by "image
dump" I mean "a tape constructed by reading, sequentially, starting at
the first block and proceeding to the last block on the disk, blocks
from a disk containing a Files-11 file system, and writing those blocks
to sequentially to a tape.)

Quote:>Why should I have to use tar(1), or dump(1M) to work with files
>the way I usually do (mt(1M) and dd(1) or simple redirection to work the
>binary of the files)?  I want the file system damn it!

*The* file system, or *a* file system?  The two are inequivalent.
 
 
 

tapes as block devices?

Post by Leo Broukh » Sat, 22 Jan 1994 06:33:23




>>        Didn't you ever want to mount a tape with (uncompressed)
>>dump of a filesystem? Read-only, of course, but it's still useful
>>if your tape driver supports it.
>     I wish the UNIX's I used supported it -- read/write too.  VMS supports
>it afterall (though I have been told it is not recommended...slow as a dog
>certainly).  Why should I have to use tar(1), or dump(1M) to work with files
>the way I usually do (mt(1M) and dd(1) or simple redirection to work the
>binary of the files)?  I want the file system damn it!

It is *VERY* unreliable to write to a tape in the middle of a file, unless
you have interrecord gaps (and probably tape marks) between records.
If you "preformat" your tape in that way, you'll be able to use it as
a random-access r/w device, but you'll lose about 30% of its capacity
(probably less, but we used to use both gaps and TMs).
You will have to write a very smart strategy for your device driver,
or else the filesystem will be slow as a very old dog...
--
        Leonid A. Broukhis  | Misce, Da, Signa: After each e-mail message.
 
 
 

tapes as block devices?

Post by Tom Limoncel » Sun, 23 Jan 1994 00:28:20



Quote:>Does VMS support mounting a mag tape with an image dump of a Files-11
>on-disk file system, or does it just support mounting a file-structured
>tape that uses ANSI standard labels to delimit files? (NOTE: by "image
>dump" I mean "a tape constructed by reading, sequentially, starting at
>the first block and proceeding to the last block on the disk, blocks
>from a disk containing a Files-11 file system, and writing those blocks
>to sequentially to a tape.)

I haven't used VMS in quite some time, but I think it actually
does this.  You could put a file system on a tape for strange
situations.  Either that, or the software fakes things enough
to make nieve undergrads think that's what was going on.

Tom  (no longer an undergrad)

--

"Psst!  Hey, Anthony!  Y'know what I        | Disclaimer:  I do not
like about existing?"  "Uh... uh... what?"  | speak for Mentor Graphics.
"Possessing a physical extension."  -TSA    |