Tape drive handling on FreeBSD

[Kern Sibbald]

On Tuesday 20 December 2005 00:20, Matthew Jacob wrote:
> >Am I wrong?  Yes, when things work, I know it is hard to get excited about
>
> making changes.
>
> But the point here is that they don't work.

:-)

>
> > 1. I believe that one can modify the FreeBSD tape API to become more
> > compatible with Solaris and Linux without breaking any programs -- simply
> > use
> > their "trick" of allowing an open() in all cases to succeed if O_NONBLOCK
> > is
> > set.  I think this is an ugly kludge, but that is how they do it. If
> > there is
> > no tape in the drive, then return a file descriptor with no read and no
> > write
> > permission, and modify them when a tape is mounted.
>
> That's probably do-able.

The only problem I can imagine is if someone already uses O_NONBLOCK on an 
open() call and expects it to fail if there is no tape in the drive.  This 
seems a bit unlikely, but a bit of documentation can avoid most problems.

>
> 2. Certainly someone can certainly figure out some magic ioctl() that
> allows
>
> > the user to set a mode so that the SCSI driver will do a forward space
> > file
> > (big number) when an ioctl( EOM ) issued.  The driver can do it *much*
> > more
> > efficiently and quickly than a program can.  The penalty is a bit of
> > speed,
> > but the gain is that the correct file number can be returned.
>
> I guess in this entire thread I missed what you're looking for here (have a
> heart- I'm on a 800x600 borrowed win98 machine in Toledo Ohio right now).

Sorry to hit you at a bad time.

> Is the problem here that you *don't* want to do 'space to EOD' when EOM is
> issued? That is, you don't want to lose your actual relative tape position
> information when seeking to append?

Yes, exactly.  Since Bacula maintains the file/block positions of jobs/data in 
a catalog, it will refuse to append to a tape if the actual EOM of the tape 
does not agree with the catalog.  A discrepency can easily occur if, while 
writing a tape, the OS crashes (a power loss of course) ...


Kern