Date: Tue, 20 Dec 2005 10:18:07 +0100 From: Kern Sibbald <kern@sibbald.com> To: Matthew Jacob <lydianconcepts@gmail.com> Cc: freebsd-scsi@freebsd.org Subject: Re: Tape drive handling on FreeBSD Message-ID: <200512201018.07905.kern@sibbald.com> In-Reply-To: <7579f7fb0512191520t484add63p40d81e2754897028@mail.gmail.com> References: <200512151122.34949.kern@sibbald.com> <200512192306.31821.kern@sibbald.com> <7579f7fb0512191520t484add63p40d81e2754897028@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200512201018.07905.kern>