|Subject:||Re: ``mt erase 0'' on a non-rewinded tape|
|From:||Ruslan Ermilov (ru...@freebsd.org)|
|Date:||Nov 6, 2002 1:22:01 am|
On Tue, Nov 05, 2002 at 08:18:52PM +0100, Joerg Wunsch wrote:
Ruslan Ermilov <ru...@FreeBSD.ORG> wrote:
The script always used to fail with EINVAL attempting to run a quick erase, ``mt erase 0''. After a bit of experimenting, it turned out that `erase' only works if I rewind the tape (either through by using the rewind device, or by running the `rewind' or `retension' commands in advance).
Please read the SCSI command description for your drive. Depending on the media type, the ERASE command will only be accepted at either beginning of medium, or at the beginning of partition for a partitioned medium. AFAICT, the FreeBSD driver doesn't support partitions anyway, so in effect, the drive will only accept the command at BOM.
OK, thanks for the explanation!
Apart from that, i don't understand your reasoning for the erase command. Since the quick erase is a logical erase command only anyway, the effect is the same like starting to write from BOT, for any practical purpose.
My tapes always look like this:
level 0 backups at Friday's evening, level 1 backups on Monday, ..., level 4 backups on Thursday. If I don't erase the tape when I do a level 0 backup, won't there be a chance that when I later do an incremental backup and do an "mt eom" it will find some stale file markers left by old incremental backups?
Whether you use the rewind or non-rewind device should make no difference, as long as the tape itself is at BOM. "non-rewind" actually means "do not rewind upon close of the device", while the state at open time is always the state the device has been left over by the last operation.
I wasn't clear enough. I meant it worked if I always used the rewind device. In this case, "mt erase" was always run at the BOM.
It's always good practice to keep the medium at BOM while the tape is not in use, since after all, that's the only position you can rely of. Otherwise, if a SCSI bus reset hit while your script was idle, the drive will rewind the tape, and next time your script is run it might make an invalid assumption about the actual tape position, thus perhaps accidentally overwriting something. OK, you wrote that you're using a "mt eom" before trying to append, so you're already safe there, but then there's no reason to not rewind the medium when finishing the script.
Yes, the script runs "mt eom" for that very reason. But why would I rewind the tape if the next day I want to use it from this same position? IOW, if the SCSI bus isn't reset in-between, I get:
# /usr/bin/time mt eom 0,01 real 0,00 user 0,00 sys
(I change the tapes once a week, at Friday's evening.)