Date: Tue, 5 Oct 1999 22:40:00 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: John and Jennifer Reynolds <jreynold@primenet.com> Cc: scsi@FreeBSD.ORG Subject: Re: questions on observed tape navigation behavior Message-ID: <Pine.BSF.4.10.9910052231130.57745-100000@beppo.feral.com> In-Reply-To: <14330.52789.99569.326161@localhost.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 5 Oct 1999, John and Jennifer Reynolds wrote: > > Hello -scsi, > > I believe this is the correct group for this question(s). > > Perhaps somebody can shed some light on the following. I've been messing around > with my TR4 tape drive lately (thanks to all those who helped me figure out the > 1 FM@EOD thing!) but have run into some questions w.r.t. navigating files on a > tape. > > First off, I'm in "variable" mode (mt blocksize 0) and am using 54k as my > blocksize when actually writing to the tape with flexbackup (port not yet > comitted, see ports/14108). The tape drive is also put into "1 file mark at > EOD" mode via a quirk entry (tapestore 8000 NS hanging off a 7890). > > I wrote 3 files to the tape--afio "dumps" of /, /var, and /home. If I > rewind the tape, I can successfully do "mt fsf 1" and seek to the next > file and do a restore operation, or "mt fsf 2" and restore the last file. > No problems here doing this. > > However, backing the tape up seems to be working non-intuitively to me. > > Consider the following sequence of ops that I performed on the same tape. > > 1) mt rewind > 2) mt rdhpos : gives '0' > 3) mt fsf 1 > 4) mt rdhpos : gives '116' > 5) mt bsf 1 > 6) mt rdhpos : gives '115' > 7) rewind again and mt fsf 2 > 8) mt rdhpos : gives '697' > 9) mt bsf 1 > 10) mt rdhpos : gives '696' > > The following is how I picture the layout of the tape (#=filemark): > > 0 116 697 > -----------------#--------------------#---------------------# <--- end of tape > ^ ^ > | | > where fsf 1 put where fsf 2 put > the head the head > > At step 5, I was expecting the tape to essentially rewind back to the > beginning. I'd gone forward 1 file, I wanted to go back one file. Same goes for > step 8-9. I seeked forward 2 files and then wanted to go back one file. I > thought that rdhpos whould have returned 116 (which apparently is the beginning > of the "2nd file" on this tape). Nope. You're confused over the 'sf' part of Bsf and Fsf. It is 'space filemark'- not 'space file'. So, after step 5 you would be: > 0 116 697 > -----------------#--------------------#---------------------# <--- end of tape > ^ and after step 8 you would be: > -----------------#--------------------#---------------------# <--- end of tape > ^ Sun used to confuse the semantics of this a bit- they invented a "Backspace File" function. This is hard to implement in hardware since tape drives typically note when a fileMARK (or a setMARK) has passed- not datablocks. So, if you want to backspace *files*, the formula is: back_space_file(N Files) = mt bsf (N + 1), mt fsf 1 Naturally this has a problem if you're only N files into the tape, so watch out for errors. If you get any error with this, assume you don't know where the hell you are and rewind. Also- as a side note- don't be alarmed if 'hardware' block numbers differ by more than one over filemarks, or even block to block. You cannot assume that they are densely packed as they are what the *drive* finds most convenient for locating to a specific spot on the tape. -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.10.9910052231130.57745-100000>