Tape drive handling on FreeBSD

[Matthew Jacob]

On 12/19/05, Kern Sibbald <kern at sibbald.com> wrote:

> On Sunday 18 December 2005 23:48, Matthew Jacob wrote:
> > The first paragraph of mtio(4) describes the usage of a control device.
>
> Yes, thanks. I've already read that and other sections of the man pages,
> and
> it is true that the .ctl device allows one to figure out if a tape drive
> really exists or not.  The problem is:
>
> 1. It is system dependent -- I would like to see some standardization of
> the
> Unix API from system to system where it is reasonable, practical, and
> doesn't
> break everything.

.....

My problem is that if I change the FreeBSD API, it breaks current usage.

Otherwise, there is no true tape device API in Unix. Look at any existing
backup package that is multi-platform. It breaks each platform into
different vectors that abstract the differences.

Don't get me wrong- I'm not promoting that there should differences. I'm
observing that nearly thirty years of Unix shows that there are and that the
way that those differences have been handled successfully by dozens of tape
backup packages (albeit with grumbling).




> 2. The errno that is currently returned by an empt tape drive during an
> open()
> is "incorrect" or at the least misleading.



The value that Solaris returns (EIO) for trying to open a tape (!O_NONBLOCK)
when no tape is loaded (i.e., fails TUR) is no less misleading.

Your complaint here is that ERRNO is not sufficient. It isn't.



> 3. The API that you currently have doesn't work correctly with Bacula,
> which
> was originally designed on Linux and Solaris -- it penalizes FreeBSD
> Bacula
> users.  Since the FreeBSD way of doing things is the minority in my little
> Unix world, it is unlikely (though possible) that I will rewrite my code.



Well, that is your privilege.



> 4. There are other shortcomings of the SCSI driver that penalize FreeBSD
> users
> compared to Solaris and Linux that I would like to discuss as well
> (ability
> to have the driver efficiently space to the end of the medium and keep
> track
> of the file position).



Despite the fact that I'm the nominal maintainer, I probably won't do that
much more. I put in a fair amount of time some years back, spent around
7500$ of my own personal money to buy tape drives to do testing with. That
said, the return value for this was more than what I got for writing the
Solaris tape driver (which is shockingly and pathetically bad, but has also
remained relatively unchanged for over 10 years). Still, the things that
penalize FreeBSD are many- the tape driver is hardly a leading candidate.



> Actually, I am really shocked how poor the "Unix" tape interface is (this
> has
> nothing to do with FreeBSD in particular). There is no standard way to set
> tape drive options, there is no standard way to figure out if a tape drive
> exists and what options it has set for it (blocking, two eof, density,
> compression, ...). Probably most annoying, there is no standard way to
> know
> if a tape is mounted or not.



Yes.




> My main interest is to try to discuss what possibilities exist for
> changing
> (unifying) the API (or there is also a small chance that I am missing
> something ...).  If no possibility of discussion/changes exists, so be it.



a) If you can get a consensus amongs more FreeBSD tape clients than you that
there *should* be convergence to, e.g., Linux, or Solaris, I certainly would
be interested. Get the Amanda and Arkeia folks on board, and we might be
able to get enough consensus to override the concerns of people even more
conservative than I am.

b) If you rewrite Bacula to actually be more platform independent you might
serve yourself better. Having maintained some of the nsrmmd code for
NetWorker/Legato, I *am* sympathetic to your concerns here. However, the
other thing I've learned, very very very very painfully, is that making
changes to existing tape interfaces (no matter how broken) will almost
certainly enrage and break more than it fixes as everyone who uses said
interfaces usually is caught by surprise when things change.

I suppose that we could have a separate SA device entry point that mandated
different tape semantics- that might help minimize breakage at the risk of
complexity. Part of the problem is that you probably are asking for a
different state machine in the driver as well.



Look- dialogue is good, but temper it with some realities please.