Date: Mon, 29 Jan 2001 19:08:09 -0700 (MST) From: Eric Lee Green <eric@estinc.com> To: Matthew Jacob <mjacob@feral.com> Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Persistent block size? Message-ID: <Pine.LNX.4.21.0101291741300.965-100000@h23.estsatnet> In-Reply-To: <Pine.BSF.4.21.0101291553230.23423-100000@beppo.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 29 Jan 2001, Matthew Jacob wrote:
> On Mon, 29 Jan 2001, Eric Lee Green wrote:
> > On Mon, 29 Jan 2001, Matthew Jacob wrote:
> > > On Mon, 29 Jan 2001, Eric Lee Green wrote:
> > > > Trying to figure this one out. 'mt -f /dev/sa0.ctl' does not give the
> > > > expected result ('mt' carps that it can't do it),
> > >
> > > You have to be a bit more prescise than 'mt carps'.
> More details than this (like, the command line you're using)
bash-2.04# mt -f /dev/sa0.ctl blocksize 0
mt: /dev/sa0.ctl: blocksize: Invalid argument
> > > What do you mean by 'persistent' parameters? Held across multiple mount
> > > sessions, or permanent across reboots?
> >
> > Held across multiple mount sessions. Having to set the block size back to
> > zero every time I insert a tape is a nuisance, though not a big one
> > because I only have to do that when I'm checking the tape format of
> > various tapes with 'mt' and 'dd' to see whether I've achieved
> > cross-platform commonality (sigh). As mentioned before, the backup
> > software itself handles that in actual production, so it's no biggie and
> > doesn't affect my software. Just that I've had that ability on The OS
> > That Shall Not Be Mentioned, and missed it on FreeBSD.
>
> Hmm.
> > > Sounds like an RFE is in the works here. Jeez, between you and Jean-Francois,
> > > it looks like I'll really have to fix things I've been putting off.
> >
> > Well, I can think of several things I'd put into an RFE, such as
> > cross-session-persistent default parameters, but right now I'm too busy
> > thinking gloomily about Solaris. (Their tape ioctl is totally worthless
> > for our purposes, meaning that we had to basically write a new tape driver
> > that issues raw SCSI commands for reading and writing data on tape... how
> > the BLEEP these guys got to be #1 in front of people like SGI that have a
> > sane OS baffles me).
>
> Well, I wrote the original Solaris tape driver back in 1990 or so (derived
> from SunOS 4.0.3c's tape driver) so you can complain to me. Hell, I might even
> be able find the current maintainer for you to talk directly with.
>
> You think IRIX is sane? Too much uncapped glue in your apartment, friend...
Maybe it's just that I've been doing SCSI media changer control, and IRIX
comes with a generic interface to the SCSI bus to allow you to access
arbitrary devices (similar to /dev/pass0 on FreeBSD), while Solaris 7 and
below do not (Solaris 8 does). Interfacing with SCSI media changers is a
pain in the #$%@ with Solaris because you have to load 3rd party kernel
modules to do it (and even on Solaris 8 you have to configure the sgen
driver to tell it what kinds of devices to map).
The big problem with Solaris, though, is the inability to get a reliable
block position out of the driver. That didn't matter in 1990, when few
tape drives supported such functionality (the SCSI-2 standard didn't come
around until, what, 1993?). But part of the reason why I'm doing what I'm
doing is because I want to take advantage of all the modern functionality
that has occurred *since* 1990.
For example, setting up current tape backup products is a pain in the
buttocks -- you have to know all about cryptic tape device node names, the
difference between rewinding and non-rewinding devices, etc., as well as
install specific drivers for your specific tape changer, etc. But modern
SCSI tape drives and changers give an amazing amount of information via
their INQUIRY and mode pages, and a modern program could (and does) do a
'camcontrol devlist' to find out how many devices there are on the SCSI
bus, make sure there are enough /dev/pass<n> devices to correspond to
those, then query each of those devices on the SCSI bus via /dev/pass<n>
to see what it is and what its capabilities are. Then it could
automagically set itself up (by being able to make the correspondence
between /dev/nsa0 and /dev/pass3, for example). It works. I'm amazed every
time I think about it. Tape backup isn't supposed to be that easy :-). I
must admit that I was skeptical when Tim mentioned the notion to me, but
when I sat down to implement it, it worked out really sweet (even if it
WAS a pain in the %@!! to implement). And by using the serial numbers, I
can even find your devices if you move them around, and make sure that
your scheduled backups keep going where they're supposed to be going --
whoa, you mean adding a tape drive at ID 1 no longer means re-jiggering
your whole backup script chain, it merely requires firing up the SCSI
scanner again? Cool! All of this relies on functionality that did not
exist in 1990.
Similarly, there's lots of tape backup products that can put a file onto
tape. Getting files off of tape, on the other hand, has traditionally been
a slow and tedious operation. Traditionally it was a case of reading one
block after the other, very very sloowly. Floppy-based tape drives didn't
even have a random access 'seek' function, and until recently that was
what most personal users had. But modern-day tape drives have very fast
and accurate ability to seek a particular data block on tape, so that you
can restore any given file without having to read through a whole tarball
(or bruball, in my case) But that relies on being able to quickly and
accurately be able to record where each file is on the tape as you write
the tape, so that you can use that directory later to find the file when
you want to restore it. MTIOCGET on Solaris is the only way to get a
mt_blkno but that mt_blkno was not accurate when we tried it. The Solaris
tape driver also gives no way of seeking to a particular tape block. Thus
we had to discard the notion of using the provided tape driver, and wrote
our own. Sucks. MTIOCKGET on IRIX will get an accurate blkno from
the drive, while MTSEEK will go to a particular block on the drive.
Anyhow: The net result is that, for our purposes, IRIX is much saner than
Solaris for writing modern tape backup software. We can actually access
the features of the drive without having to write our own SCSI tape
driver. Solaris's tape driver in Solaris 8 (the only one I'm messing with)
has lots of neat features for handling fibre channel subsystems, but won't
access any of the advanced features of the tape drives themselves (where
"advanced features" is any feature that has become common since you wrote
the original back in 1990). I won't comment on other features of IRIX
because all I know about IRIX is the tape subsystem (from a user
perspective)... all I'll comment is that, from a tape driver perspective,
IRIX makes Solaris look pathetic. Porting between Linux and FreeBSD is
easy (it took me maybe 2 man-days to port BRU Professional to FreeBSD, not
counting all the bugs in my networking code that were uncovered by the
fact that FreeBSD works the way Unix is supposed to while Linux masks many
bugs with its non-standard networking implementation). Porting between
Linux, FreeBSD, and IRIX is easy -- I estimate that the IRIX port would be
2 man-days also. Solaris, on the other hand, is a pain. My existing
system-dependent low-level driver module reports "Not Implemented" for
large chunks of missing functionality on Solaris. This is a signal to the
higher-level code to dump the notion of using the tape driver for that
functionality, and instead start issuing raw SCSI commands. Note that once
you start issuing raw SCSI commands, that's pretty much it -- you aren't
going to use the tape driver anymore, because it gets confused (much as if
you used both pass0 and /dev/sa0 on FreeBSD). Thus once the higher level
system-independent code decides that the system-provided tape driver is
useless, we effectively have our own tape driver on Solaris.
Sorry about the long ode to IRIX. I know it's not really relevant to this
list. It's just that I've been cursing tape drivers for too long (even
relatively good ones like on FreeBSD and Linux occasionally raise my ire
when I run into some quirk, such as the broken partition support in the
Linux 'st.c' module, though since DLT/Dumb Linear Tape does not support
partitions I had to dump the notion of using partitions for fast on-tape
catalogs anyhow), and finding one that is actually sane is an experience
akin to an angel descending from the heavens and blessing me. Besides, I'm
procrastinating -- I'm supposed to be doing more work on Solaris at the
moment (FreeBSD is working perfectly for QA now that I fixed all my
networking bugs, so I don't have any excuse to mess w/FreeBSD anymore,
alas, alak). Okay, so maybe my viewpoint is parochial. Maybe looking at
systems from the viewpoint of their tape drivers isn't the best way to
judge systems, but every time I compare the IRIX and Solaris tape drivers,
I mutter "How did those people at Sun ever become #1 in the commercial
Unix industry?". Solaris makes my life hard, IRIX makes my life easy, and
(shrug) from my point of view, that's all I care about.
Meanwhile, if you haven't checked out an IRIX system recently, you might
want to take a look at what they've done to their tape driver. I see
nothing there that really cries "this must go into FreeBSD!", since by
going to /dev/passX using 'tapeinfo' I can get the same info, but they
still have some pretty cool capabilities in there.
--
Eric Lee Green eric@estinc.com
Software Engineer "The BRU Guys"
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.21.0101291741300.965-100000>