Date: Mon, 19 Dec 2005 14:12:09 -0500 From: Matthew Jacob <lydianconcepts@gmail.com> To: Kern Sibbald <kern@sibbald.com> Cc: freebsd-scsi@freebsd.org Subject: Re: Tape drive handling on FreeBSD Message-ID: <7579f7fb0512191112n3a5d8a5ai6e27587a39c7023b@mail.gmail.com> In-Reply-To: <200512191034.52756.kern@sibbald.com> References: <200512151122.34949.kern@sibbald.com> <7579f7fb0512181448x1dc4b3f4m9d5112cc6bc9fc1a@mail.gmail.com> <200512191034.52756.kern@sibbald.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/19/05, Kern Sibbald <kern@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 th= e 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 littl= e > 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 se= t > tape drive options, there is no standard way to figure out if a tape driv= e > 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 tha= t there *should* be convergence to, e.g., Linux, or Solaris, I certainly woul= d 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7579f7fb0512191112n3a5d8a5ai6e27587a39c7023b>