Date: Mon, 28 Aug 2000 22:39:41 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Greg Lehey <grog@lemis.com> Cc: Sam <freep@thecity.sfsu.edu>, freebsd-scsi@FreeBSD.ORG Subject: Re: "tape is now frozen" Message-ID: <Pine.BSF.4.21.0008282223590.36166-100000@beppo.feral.com> In-Reply-To: <20000829145223.Z11422@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 29 Aug 2000, Greg Lehey wrote:
> On Monday, 28 August 2000 at 22:15:41 -0700, Matt Jacob wrote:
> >
> >>
> >> I've lost the *exact* position. In fact, I'm not even sure I've lost
> >> the exact position, but I'm prepared to concede that. Within a block
> >> or so I know where I am.
> >
> > You cannot know that.
>
> Of course I can. I've just typed:
>
> # mt fsf 3
> # tar tv
> Cannot read 65536 byte record.
> Tape is now frozen. Jump over your left shoulder to recover.
But this is wrong. You should have typed, if you don't know the format of the
tape:
# mt rewind
# mt blocksize 0
# mt fsf 3
# tar tv
If *this* gives you the 'tape frozen' message, that's a bug. Let me know.
I *do* want to know what specific error you are running into here.
Is it because you're in the middle of the tape and you forgot the blocksize?
See below.
If it's because you wandered off the end of recorded media, I *think* I could
be convinced that that counts the same as an 'mt eom' unfreeze- but I'd have
to think long and hard about whether this works on *all* tapes.
But I think I see what you're asking below.
> (yes, these aren't the original messages, but I didn't want to go to
> the trouble of finding a suitable tape and actually doing the
> experiment).
>
> At this point, I know that in all likelihood the tape has got to the
> end of the record and is (logically) positioned on the IRG. It may be
> somewhere in the middle, but that doesn't matter. If I do the
> following:
>
> # mt bsf 1
> # mt fsf 1
> # tar tvb 128
>
> it should work.
Okay. You're saying that if I've lost position that backing up over the
previous filemark and then skipping forward should get me back to where I was
at the failed operation.
In some cases this is true- but not in all cases!! It depends on what the
*actual* error that causes the failure to occur. That is- you're asking me to
believe that a a failed read (because of block size error) does *not* in fact
skip multiple filemarks.
For all the tape drives we support would you care to bet your nuts (this is
not a joke- assume a FreeBSD system is being used to read radiologic image
data from a tape- a cancer screen for testicular cancer for *you personally*)
that this can't happen? An extreme case but......
EOM, BOT and OFFLINE are unequivocally knowable states.
Like above- I *might* be able to convince myself that a read of hardware
position after either an mt sethpos or an fsf/bsd that succeeds could be good
enough evidence that there's a closer known place to get back to than BOT. But
I'd think damn long and hard about it.
> I don't see that in this case. Is that the scenario you're talking
> about?
If you don't know the position, you don't know the position. It's thatsimple.
If you're always augmenting position with human info, like a 'tar tvf', or
like NetWorker *never* assumes it knows really where it is on tape when it
gets ready to read or write, that's fine.
But it's inappropriate for the driver to assume this type of behaviour.
>
> > It's just barely possible to concede that a (successful) report of
> > hardware block position could be construed as "setting
> > location". But this also means that all other notions of file
> > location can not be known any more.
>
> I'm not even going to argue that one. It seems to me that once you've
> lost position within a file, you've lost position. But you know
> you're between two file marks.
But which ones? It's not clear to me you can assume the failed read case
didn't skip over several.
Probably not, but I sure wouldn't want to guess.
I still don't see why you can't remember to do 'mt blocksize 0'.
I'd like to remind you all that you can just comment out all
softc->flags |= SA_FLAG_TAPE_FROZEN;
in scsi_sa.c if you don't like the behaviour. It's your power saw.
Watch those fingers!
-matt
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.BSF.4.21.0008282223590.36166-100000>