*BSD News Article 91763


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.mel.connect.com.au!munnari.OZ.AU!news.ecn.uoknor.edu!feed1.news.erols.com!howland.erols.net!news.mathworks.com!fu-berlin.de!irz401!orion.sax.de!uriah.heep!news
From: j@uriah.heep.sax.de (J Wunsch)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Tape file system
Date: 23 Mar 1997 20:51:27 GMT
Organization: Private BSD site, Dresden
Lines: 82
Message-ID: <5h454f$ii7@uriah.heep.sax.de>
References: <5h0pfc$7vg@fu-berlin.de>
Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
NNTP-Posting-Host: localhost.heep.sax.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Newsreader: knews 0.9.6
X-Phone: +49-351-2012 669
X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F  93 21 E0 7D F9 12 D6 4E
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:37634

gusw@zedat.fu-berlin.de (Gunther Schadow) wrote:

> is it possible to write a file system onto a tape and then mount it
> like a disk? Wasn't this possible on the VAX?

It's only possible for block-addressable tapes.  For writing, this
means you need a 9-track half-inch reel-to-reel tape.  For read/only,
you might perhaps get away with a DAT tape already.

Of course, you need the silly old unix file system for it in order to
do something halfways reasonable at all.  Using the disk-optimized
Berkeley FFS is most likely nothing else than a good hardware test for
your tape drive. :-)  (Maybe it you can simulate the old behaviour
by forcing everything into a single cylinder group.)

The tape block device nodes (/dev/st0, major #5, minor #0) in FreeBSD
are broken for some reason.  You can't really read or write something
with them.  I once tried to debug the problem, but eventually gave up.

Sure, it would be something worth to do for fun (in particular if one
still has a half-inch drive, too ;-), but it's nothing you would ever
use for serious work at all.

> On HP-UX you can even
> boot from tapes, can't you?

That's a different problem.  Something you probably won't ever get
with a PC, simply since the BIOS manufacturers don't even believe
somebody would have a use for this (what you would need in order to do
this is some kind of BIOS device access in the BIOS ROM).

This is totally unrelated to filesystems.  It's usually done by using
a tape file containing a memory filesystem image, or by using a
filesystem image that is installed in the swap area as a so-called
miniroot.

> An other question is, why (or whether) lseek is not yet implemented
> like doing fast seeks as `mt fsr ...', any problems here? Should
> I just add an lseek system call for the st.c driver?

No such thing like an lseek entry point to the device drivers.  All
that lseek(2) does is to notify the upper layers that the next request
will go to a different address; this is in no way passed down to the
device drivers.  All the device drivers see is that the next buffer
passed to the strategy entry point is on a different device address.

Translating this into a tape seek operation might seem useful,
although it's not very simple.  It's not supported by all tape drives
anyway, and for those that support it, you need to ensure that the
request won't go beyond the limits of the current tape file.  (How do
you handle different tape files in an lseek() context anyway?)  Also
note that some tape drives, while offering the ability to go backwards
by one record, simply have a _terrible_ performance doing this (i know
it for example for the good ol' Archive Viper 150).  They can only
read forward, thus in order to go one record backwards, they go a
larger amount backwards, and read ahead until the next tape block is
under the head.  Seeking back by 100 records on them is an operation
taking about 2 hours...

> I am asking because I feel like the tar (`Tape ARchive') is not as
> well tailored as it could be, ...

It ain't, but its actual value is not that it would handle tapes in an
efficient manner, but in that it's a fairly universal archive format
that is understood by many systems.  Unfortunately, you're some 10 or
20 years too late if you wanna change the tar format today. :-)

> Dump(8) has a nice directory feature `restore -i'is very comfortable,
> however, restore does not seek quickly but reads over the whole tape.

Restore could perhaps be taught to use the MTIO* ioctls in order to
seek to the desired block, as opposed to reading all the blocks.
However, take care to not break the end-of-medium handling.  When you
read a restore tape, you never know which is the last i-node present
on the current tape, until you perused through end-of-medium...

-- 
cheers, J"org

joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)