Mitch Collinsworth wrote:
>
> On Mon, 12 Feb 2001, Chris Karakas wrote:
>
> > The tape, on the
> > other side, did not have its headers updated (not the AMANDA headers,
> > but its low level headers - on my system this is done at the end of the
> > flushing, after the rewind command is issued), so the drive will not
> > find the transfered files on it. The result was that all the transfered
> > images were lost :-(
>
> Huh?! Upon reading this I had two distinct reactions:
>
> 1) Whatever this device is, it sounds like it no longer conforms to
> the commonly accepted definition of a tape drive. Please tell us
> what it is so we can avoid buying one.
This is a QIC-3020 drive, a Colorado 1400. It is a so-called floppy
drive.
That the QIC tapes have to have a header segment is a requirement of the
QIC standard. So I have to refer you to the QIC committee, if you think
those headers do not conform to the "commonly accepted" definition of a
tape (drive). QIC development standards can be found at the QIC
organisations home page (http://www.qic.org) where you can get the
latest standards in PDF format.
If you think that it is O.K. for a tape to have headers, but your
reaction pertains more to why they are updated at the end, then this is
a driver issue and you should contact the maintainer of the floppy tape
driver for Linux, Claus-Justus Heine ([EMAIL PROTECTED]).
Here is what he says in the ftape manual:
-----------------------------------
Not only that the non-rewinding devices do not rewind the tape when the
driver is closed, they also cache a lot of data
which belongs to the header segments or the volume table segment. This
is done because synchronising all that data
with the data on the tape cartridge would mean to rewind the tape to BOT
and then write and verify three floppy tape
segments which would take some minutes.
However, this caching practice is dangerous as floppy tape drives
provide no measure to prevent cartridges from being
removed from the tape drive (there is no door that could be locked)
No rule without exception: the Iomega Ditto Max drives indeed have
load and unload commands as
well as door locking facilities. ftape uses them if it detects such
a tape drive.
. Therefore one has to be careful with the ftape driver in the sense
that one must not forget to rewind a cartridge before
removing it from the tape drive. Use
mt -f /dev/qft0 rew
before removing the cartridge; possibly replacing /dev/qft0 by the
device node you have used when writing to the
cartridge used.
-----------------------------------
As you see, it is caching as usual, nothing more and nothing less. It's
the method, not the hardware.
> I hope the manufacturer is
> honest enough to market it with a large warning label:
>
> "WARNING: This is not your grandfather's tape drive. Data
> loss may occur! Buyer beware, etc, etc"
>
Suppose you told me that you have a kernel which caches filesystem
information, as a result of which you have to always run sync before
plugging it off the mains. And suppose that I told you "oh, what a
terrible kernel you have, please tell me who wrote it and if he was
honest enough to put a disclaimer that his kernel might cause data loss
if you just turn the computer off", how would you find it? You get my
point.
The manufacturer is Colorado Backup Systems, now owned by HP. The same
drive has been marketed as a HP Jumbo, or similar. I don't know how
honest HP is but it should be at least as honest as IBM, Quantum, or any
other well-known drive manufacturer.
Let me tell you that
* the drive works fine for 5 years now, without any problems
* it does *not* need head cleaning, probably because it does not touch
the cartridge (and this is probably the reason it lives so long)
* due to the sophisticated hard-error-recovery code of the linux ftape
driver, I never had to throw away even 1 (one) tape away :-) Even the
oldest ones work fine (3M MC3000XL). This speaks not only for the
quality of the tapes, but also for that of the driver: if a segment is
found to be bad, it is marked as such (in the bad sectors map, located
in the tape headers mentioned above) and is not used anymore.
* I always do a amverify on my tapes. I never got errors. Of course,
there are errors in reading, but they are caught by the CRC
error-correcting code of the ftape driver :-)
* and generally the drive cooperates marvellously with AMANDA
> 2) Are you sure about this? I.e. have you tried a dd against
> such a tape and really not been able to pull anything off it?
>
amverify does this each and every time I run it (and that means: every
day, after amflush :-))
> Also, how exactly does your system update these low level headers?
>
See above.
> Given you description of this "tape drive"'s operation I would
> say you are completely justified in not trusting it. YIKES!!
Oh, I see... so you trust your drive? Or your hardware in general? ;-)
So let me now ask you some questions:
* how often does your drive hang?
* how often does it need head cleaning?
* how often do you need to throw away a tape just because one (1)
segment on it is bad and your tape driver or drive cannot handle it?
* how many errors do you get reading your data from the tapes? Do you
always run amverify on them?
* and the most interesting one: if you pull the server out of the mains
while running amflush, what happens to the files already flushed on your
tape? Can your drive/driver find them (at least up to the last tape
block that was written completely)?
--
Regards
Chris Karakas
Don´t waste your cpu time - crack rc5: http://www.distributed.net
