Date: Tue, 29 Aug 2000 14:52: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: <20000829145223.Z11422@wantadilla.lemis.com> In-Reply-To: <Pine.BSF.4.21.0008282211050.36166-100000@beppo.feral.com>; from mjacob@feral.com on Mon, Aug 28, 2000 at 10:15:41PM -0700 References: <20000829131721.R11422@wantadilla.lemis.com> <Pine.BSF.4.21.0008282211050.36166-100000@beppo.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. (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. >>> The whole point of rewind, eom or offline is to bring the tape to a >>> *known* place. Spacing one filemark is not sufficient. >> >> Why not? We know we're at the beginning (or end) of a file. > > I have fifty files of *almost* identical data. If I think I'm at > file 43, but I'm at file 42, that's wrong. If tape position has been > lost, it's been lost. It's more than a "little bit" pregnant. I don't see that in this case. Is that the scenario you're talking about? > 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. >> Well, no, I state it above. >> >>> It has occurred because there was an I/O error, or you're not using >>> the tape correctly (fixed block mode and you don't issue the correct >>> read size). >> >> Precisely. But that's not a reason to penalize people by making them >> wind from one end of the tape to the other. > > Argh!!!!! I just plain don't agree, Greg. I'm sorry. If you don't know what > the blocksize is, switch to variable mode. Even then- what's the big deal. > You're not in the middle of the tape- you're at the front of the tape if you > don't know. > > I really don't want to change this behaviour. It's wrong to allow > people to do things that would encourage data lossage. Do you still maintain this in the case of the example above? 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?20000829145223.Z11422>