Date: Sat, 13 Jan 2001 16:46:18 -0700 (MST) From: Eric Lee Green <eric@estinc.com> To: freebsd-scsi@FreeBSD.ORG Subject: Re: Why filemarks in sardpos? Message-ID: <Pine.LNX.4.21.0101131547160.6204-100000@h23.estsatnet> In-Reply-To: <Pine.LNX.4.21.0101131422110.6204-100000@h23.estsatnet>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 13 Jan 2001, Eric Lee Green wrote:
> +#ifdef STUPID_IDIOTIC_MORONIC_STUFF
> if (softc->flags & SA_FLAG_TAPE_WRITTEN) {
....
One final note, since apparently there is some misunderstanding -- the
above #ifdef was put in during a caffeine-fueled midnight hacking session
where I was about ready to toss the computer out the window. It has
nothing to do with Matthew Jacob, FreeBSD, or anything other than the
idiotic moronic tape drive firmware authors who conspire to make things
difficult for those of us attempting to use their devices for more than
doorstops.
The Linux equivalent of sardpos in st.c has been tested with every drive
that is listed on the Linux Tape Cerification page (
http://www.linuxtapecert.org ) as well as with various other drives that
were not "officially" certified. I did not do this testing. I was not
involved in this testing. The QFA code in BRU 16.1 has been thoroughly
tested under Linux using the st.c driver as part of the BRU Professional
product, which has been in beta test in production environments since late
November. Again, I did not write the Linux code, and I was not involved in
testing the Linux code, the author of that code and our QA department did
that.
Comments upon reliability: BRU 16.1 (and BRU Professional) do not require
the logical tape position as reported by the tape subsystem during backups
to be absolutely, 100% accurate. I know of no enterprise tape backup
product with such a requirement, because tape drives just don't work that
way. As long as the logical tape position reported is within 100 blocks or
so of the "real" logical tape position, we'll find the file on tape,
thanks to various retry and fallback mechanisms that will go on a "hunt"
in the general neighborhood. EST has been in the tape backup business
since 1984. The guy who spec'ed the QFA for BRU 16.1 had over 20 years
experience in the tape backup business (including being project manager
for a predecessor to Legato Netbackup). The guy who designed and wrote the
QFA code in BRU 16.1 has been in the business for more time than I like to
think about. As a matter of course he put things into that code to handle
things that I would never have thought of as being potential problems. *IN
PRACTICE* we have found that the Linux st.c driver reports numbers that
can be directly fed to LOCATE to position exactly to where we need to be,
but nowhere do we absolutely require that to be true.
We do require accurate logical tape positions for where the start of an
archive is located, but we can handle that at the applications level.
We rely more on tape marks for that anyhow.
I have a copy of the SSC standards here, but use it only as a guideline.
As with the SMC standards (which I have pretty much memorized as the
maintainer of mtx), any relationship to what tape drive vendors' products
actually do is coincidental. I also have a shelf-full of vendors'
SCSI-level drive manuals, which are more useful in many cases because they
say what the drives really do, rather than what the SSC committee wished
they'd do. EST also has a lab full of tape hardware which EST employees
are busily certifying with BRU Professional, and that actual tape hardware
is what is the final detirminant of what works and what doesn't work.
Again, my apologies to those offended by the #ifdef. As for the tone of my
messages, I realize I'm not the most diplomatic person in the world. The
code as currently exists in the FreeBSD sa.c driver is useless in real
world applications because it's too slow. I know there's sleazy salesmen
types who could sugar-coat that to be more palatable, but if I had that
gift, I'd be a manager, not an engineer. (shrug). Feel free to ignore the
tone of any of my messages and focus upon the content.
--
Eric Lee Green eric@estinc.com
Software Engineer "The BRU Guys"
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.21.0101131547160.6204-100000>