From: Andrew Morton <akpm@linux-foundation.org>
To: Kern Sibbald <kern@sibbald.com>
Cc: Kai Makisara <Kai.Makisara@kolumbus.fi>,
linux-scsi@vger.kernel.org, Willem Riede <wrlk@riede.org>
Subject: Re: Linux tape drivers
Date: Tue, 3 Apr 2007 13:39:04 -0700 [thread overview]
Message-ID: <20070403133904.0029ccd2.akpm@linux-foundation.org> (raw)
In-Reply-To: <200704031508.37222.kern@sibbald.com>
(cc's added, with permission)
On Tue, 3 Apr 2007 15:08:37 +0200
Kern Sibbald <kern@sibbald.com> wrote:
> Hello,
>
> I am the project manager for Bacula, an Open Source network backup program
> that runs on all popular OSes. After your presentation at FOSDEM in Febrary,
> we briefly talked about Linux tape driver problems I am encountering, and you
> offered to put me in touch with the appropriate kernel developers.
>
> I would much appreciate any help in this. Since the problems concern all tape
> drivers, I provide a very brief outline of what my would like to discuss.
> First, I must mention that the Linux SCSI driver works perfectly fine with
> Bacula, it is simply a question of possible improvements, under item 2 below.
>
> Issues for discussion:
>
> 1. Bugs:
> a. Other than the OSST driver, apparently no IDE/SATA tape driver works
> with Bacula. I don't have such a drive (working on it), but from user
> reports, it appears to me that there are problems of permitting
> variable length blocks, and more serious, when writing to the end of
> the tape, either the logical end of tape indicator is ignored, or when
> it is encountered, all further I/O is prohibited -- including a WEOF.
> This makes reliable writing of multiple reel tapes impossible.
>
> By the way, these IDE/SATA drives work with Bacula using the same
> source code cross-compiled with GNU C++ on Linux, then run on Windows
> machines, so it is most likely a driver issue rather than anything in
> Bacula or the hardware.
>
> 2. Usability of the current tape driver API (not bugs)
> a. With the new O_NONBLOCK flag introduced in kernel 2.5.x, opening
> a tape drive and finding out if a volume is mounted is much more
> complicated. It is really inconvenient and required a lot more code
> in prior kernels. This should be an item for discussion.
> b. There is no simple way to determine if a tape is in a drive -- it is
> at least 20 or 30 lines of C code to do it right.
> c. There is a real lack of information about any error condition
> (read/write). One can probably get it via direct SCSI commands, but
> why not through an ioctl.
> d. The same as c. above, but for all kinds of error information that
> can be important -- particularly soft errors. An ioctl() that returns
> additional information could be very useful. Currently we get it by
> using external SCSI programs such as mtx tapeinfo for TapeAlerts,
> and smartclt for errors.
> e. Apparently only root can do the following (IMO, this is a bug or
> programming oversight):
>
> struct mtop mt;
> mt.mt_op = MTSETDRVBUFFER;
> mt.mt_count = MT_ST_CLEARBOOLEANS;
> mt.mt_count |= MT_ST_FAST_MTEOM;
> ...
> ioctl(fd, MIOCTOP, &mt);
>
> Typically Bacula runs tape daemon as non-root. Is there a good reason
> why program that has write permission on the device cannot do this
> ioctl() and is it possible to change this?
>
> There are probably a few other items that I have forgotten. I consider #1
> rather important (at least for Bacula). Item #2 is something more long term
> and some of my requests may have compatibility issues to consider.
I don't think that any particular individual maintains the tape code as a
whole, so progress will probably be slow, I'm afraid.
Kai maintains the scsi tape driver and Willem looks after OSST. Perhaps they
can comment on some of the issues which you identify?
Thanks.
next parent reply other threads:[~2007-04-03 20:40 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200704031508.37222.kern@sibbald.com>
2007-04-03 20:39 ` Andrew Morton [this message]
2007-04-03 21:30 ` Linux tape drivers Kern Sibbald
2007-04-03 21:57 ` Andrew Morton
2007-04-03 22:15 ` James Bottomley
2007-04-04 3:00 ` Willem Riede
2007-04-04 14:26 ` Kern Sibbald
2007-04-04 18:55 ` Andrew Morton
2007-04-04 19:21 ` Kern Sibbald
2007-04-04 20:37 ` Andrew Morton
2007-04-04 19:22 ` Willem Riede
2007-04-04 20:39 ` Andrew Morton
2007-04-04 21:31 ` Bartlomiej Zolnierkiewicz
2007-04-04 21:43 ` Andrew Morton
2007-04-04 18:46 ` Kai Makisara
2007-04-04 19:50 ` Douglas Gilbert
2007-04-04 20:58 ` Kern Sibbald
2007-04-04 21:54 ` Kai Makisara
2007-04-05 8:32 ` Kern Sibbald
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070403133904.0029ccd2.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=Kai.Makisara@kolumbus.fi \
--cc=kern@sibbald.com \
--cc=linux-scsi@vger.kernel.org \
--cc=wrlk@riede.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox