Date: Mon, 28 Aug 2000 23:06:56 -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.0008282259480.36166-100000@beppo.feral.com> In-Reply-To: <20000829152823.D11422@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > # 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. But what's wrong with always defaulting to blocksize 0 (variable)? Except for QIC tapes, you then can always not give a hoot as to what the actual blocksize is. > > 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? That's correct. > .. > 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. If all tape drives were like a 1/2" 9 track, yes, I'd buy this. But what we typically have is a tremendous amount of emulation occuring- and it's this emulation I'm mistrustful of. > .. > > 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. Like I said- if I could be sure of this, I'd buy the steps you proposed. I still think that the 'read hardware position after an fsf or a bsf' as a place to 'return to' might be acceptable. > 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). Hmm. Well, it doesn't happen to me. I'm about to pop the hood on the tape driver anyway again- Sam's helped me find a couple of breakages anyway. Guess it's time to sort this out once and for all. -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.0008282259480.36166-100000>