Date: Tue, 29 Aug 2000 15:28:23 +0930 From: Greg Lehey <grog@lemis.com> To: Matthew Jacob <mjacob@feral.com> Cc: Sam <freep@thecity.sfsu.edu>, freebsd-scsi@FreeBSD.ORG Subject: Re: "tape is now frozen" Message-ID: <20000829152823.D11422@wantadilla.lemis.com> In-Reply-To: <Pine.BSF.4.21.0008282223590.36166-100000@beppo.feral.com>; from mjacob@feral.com on Mon, Aug 28, 2000 at 10:39:41PM -0700 References: <20000829145223.Z11422@wantadilla.lemis.com> <Pine.BSF.4.21.0008282223590.36166-100000@beppo.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, 28 August 2000 at 22:39:41 -0700, Matt Jacob wrote: > > > 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 Right, assuming I knew this in advance. > If *this* gives you the 'tape frozen' message, that's a bug. Let me know. I'm planning to try it, but I'm not expecting any problems there. > 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? Yes. Or because I didn't know it in the first place. > 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. Hmm. If I've reached the end of the tape, yes, I suppose I'd want to be able to carry on writing without first counting how many files I had hit and rewinding. But then I should be able to do an mt eom, right? >> (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. I'd really like to see a case where that could happen. If the read length is too long, we just get a short read back, right? And if it's too short, the furthest you can hope for is to end up at the end of the block anyway. > 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 think it's worth a good think. And yes, I know we have a lot of junk tapes out there, on which I wouldn't bet my nuts with or without this feature. >> 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. Nope, you can say "I don't know the exact position, but I know it's somewhere between here and there". It looks to me like the real issue is understanding how far off we can be after a tape error. I can't see any way to end up past a file mark, at least not on the kind of error we're seeing here. >>> 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'. Because I'm stupid. Seriously, though, I'm representing all the people out there who don't think about this every time (and I certainly do that often enough myself). Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers 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?20000829152823.D11422>