-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thus spake Brett Lymn ("BL> ") sometime Today...

BL> Use the raw device when using tar/dump/pax because they are writing
BL> their own data format.
BL>
BL> Don't get "block interface" confused with tape blocking, they are
BL> different things, tape blocking is used to increase performance by
BL> writing large amounts of data to the tape at one time.  The idea being
BL> that if you can feed enough data consistently then the tape will
BL> stream which is much faster than it constantly doing a stop,
BL> reposition, write - the larger writes gives the machine more breathing
BL> space to get the next chunk of data ready to feed to the tape drive.

"Tape Blocking" is merely a term assigned to writing data of a fixed
length -- whether or not it increases performance depends upon the blocking
factor.

As I understood it, the block interface is a form of tape blocking --
it is just non-optimal.  /dev/st? is usually used in those scenarios
which warrant a 'boot-n-root' tape (which you mentioned, below).

BL> The block interface (/dev/st) will read and write data in blocks of
BL> 512 bytes (the standard block size), this is more useful on disk
BL> drives and is, indeed, what the standard file systems work on (ever
BL> noticed how newfs uses /dev/rxx but you mount /dev/xx?).

Are you sure it's 512 across the board?  I thought it was 2k, or, at
the very least, 1k, which is the smallest blocksize some tape drives
are known to handle.  I know, for example, that EXB-8x0y tapes didn't
handle anything less than either 1k or 2k (512 caused a driver error).

BL> Theoretically (and some old OS'es supported it) you could put a file
BL> system on a tape.  You need the right sort of tape drive (one that can
BL> rewrite individual blocks) and it would be slow as something extremely
BL> slow.  Having said that, I am reasonably sure that NetBSD does not
BL> support putting a fs on a tape, but if you could then you would be
BL> mounting /dev/st0...

Pity.  I know it seems archaic, but as tape will really never go away,
realistically speaking -- at least, certainly not in the near future --
it would be very cool to support tape booting.

By the way:  I never EVER knew of a re-writable FS on tape, not even with
individual blocks, simply because of the geometric unpredictability of
tapes (this was something I encountered on one of my first large-scale
projects at a four-year job which served, effectively, as a four-year
intensive CS-JOAT110 course for me).  I told one of the experts there
at work what I was doing, and they advised me, "You're not *really* planning
on updating tape records, are you?"...

Now all I need is to get my 850x up and going (and I should see if I can
get the changer and the drive to interact), and maybe I could actually
get a fs-on-tape (1k/1k)...

BL> --
BL> Brett Lymn
BL>


				--*greywolf;
- --
"Yikes!" said Wile E. Coyote.
"Beep! Beep!" said the Road Runner.
"" said the SPARC, not encountering the same errors while compiling X11R5.
[ the Sun 386i was also known as the "Road Runner". ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFBIN80PHvwcY2+w1kRAnDsAJ9k9QxCHPG6eZMRzPZqSRUIdoGdGQCfZ2lD
Ia/1/GS0IiXGK7V3/vsNAtU=
=y34j
-----END PGP SIGNATURE-----