Date: Thu, 18 Jan 2001 15:06:20 -0700 (MST) From: Eric Lee Green <eric@estinc.com> To: Mike Smith <msmith@FreeBSD.ORG> Cc: mjacob@feral.com, freebsd-scsi@FreeBSD.ORG Subject: Re: Troubles with Mammoth2 if there is a tape error Message-ID: <Pine.LNX.4.21.0101181401140.9054-100000@h23.estsatnet> In-Reply-To: <200101182023.f0IKNNQ00888@mass.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 18 Jan 2001, Mike Smith wrote: > > Well, I can annoy the frick out of even more people and declare that Deferred > > Media errors *also* make the tape state frozen (thus nuking dd and causeing > > you to do an EOM, REWIND or OFFLINE to get state back to a known place > > (actually, setting specific block position should do it too- need to remember > > to do this...).... Allowing setting specific block position to clear state would be useful for some backup programs, I think, ones that try to verify the current tape before moving to the next one. BRU Pro does not do that (it does the write, no matter how many tapes it takes, then does the verify starting back with the first tape, in an attempt to reduce the backup window), but I can see how people with standalone tape drives in particular would prefer a backup program that did the verify on a tape-by-tape basis. This would also allow the backup program to detirmine how many blocks of data actually did get written, so that it knows how many blocks (out of its buffer) need to be prepended to the next tape prior to starting to write new blocks of data. > A 'deferred media error' basically just tells you that the tape you've > just written is now junk (because it's corrupt), and the only correct > actions I can think of are: > > - eject and discard > - rewind, erase and retry The nastiness behind 'deferred media error' is that it means that data was reported written to the tape when it actually did not make it to the tape. This is Evil(tm). This means that the backup program lost data without knowing it. With BRU or afio that means you'd lose a block or two of data, maybe one or two files. With compressed or gzipped 'tar', that means the rest of the archive is unreadable. Now you know why I prefer afio or BRU to 'tar' for tape backups (if I didn't work for the BRU guys, I'd use afio). In any event, the important thing is that it gets reported as an error to the tape backup program as soon as possible. The tape backup program will then rewind the tape, eject it, and ask for the next tape (well, it'll rewind the tape and eject it if it's a tape program that's more sophisticated than 'tar' :-). . Whether the tape backup program starts rewriting from scratch or decides to continue where it left off (perhaps prepending the new data with some buffered data that was written at the end of the previous tape) is an issue for the applications writer. So yes, I think that a deferred media error making the tape state frozen would probably be preferred by tape backup software authors. Of course, if it happens to break *MY* software I'll be yelling as much as the rest of the crowd (grin). -- 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.0101181401140.9054-100000>