From owner-freebsd-scsi Mon Aug 28 23: 7:10 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 8C0CC37B422 for ; Mon, 28 Aug 2000 23:07:07 -0700 (PDT) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id XAA25790; Mon, 28 Aug 2000 23:06:59 -0700 Date: Mon, 28 Aug 2000 23:06:56 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Greg Lehey Cc: Sam , freebsd-scsi@FreeBSD.ORG Subject: Re: "tape is now frozen" In-Reply-To: <20000829152823.D11422@wantadilla.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > # 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