Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!sgi!shinobu!odin!anchor!olson
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: Question bru-ing again!!
Message-ID: <1991Feb14.020542.8248@odin.corp.sgi.com>
Date: 14 Feb 91 02:05:42 GMT
References: <9102122035.AA22599@igor.tamri.com> <1991Feb13.043605.17095@odin.corp.sgi.com> <1991Feb13.061746.21283@portia.Stanford.EDU>
Sender: news@odin.corp.sgi.com (Net News)
Organization: Silicon Graphics, Inc.  Mountain View, CA
Lines: 45

In <1991Feb13.061746.21283@portia.Stanford.EDU> dhinds@elaine21.stanford.edu (David Hinds) writes:

| In article <1991Feb13.043605.17095@odin.corp.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes:
| >In <9102122035.AA22599@igor.tamri.com> sissi@IGOR.TAMRI.COM (Sissi Tchehrazi) writes:
| >| 	
| >| 		mt fsf (advances my 8mm tape one file)
| >| 			at this point I will like to write a new file
| >| 		bru -cvf /dev/nrtape (8mm is linked to tape size=0K ..)
| >| 				result:
| >| 		bru: Warrning Input/Output Error
| >| 		bru: load volume 1 and enter ....
| >
| >Because while 8mm drives can append at any FM, it has to be on the
| >BOT side of the FM.  So you have to do mt fsf 1, mt bsf 1, if I
| >remember correctly.  Remember that the new EOD is where you stop
| >writing, you can't just overwrite part of the data.
| >
| >mt feom takes care of getting you on the correct side of the FM;
| >I'm not sure right now if we made the append at any filemark work in 3.2 or
| >3.3, or perhaps not till 4.0
| 
| I don't think this is right.  I'm pretty sure the 8mm drives can't back
| up except when rewinding, so "mt bsf 1" won't work.  "mt feom" puts you at
| EOD, which has to be on the far side of whatever other marks are put down
| at the end of a file.

Nope; I have no idea where you got the idea that 8mm drives can't bsf or bsr,
but having written the driver, tested it, and used it numerous times, I can
assure you that it can do these things!

The 8mm drive doesn't support the direct space to end of media command
either, unlike every other scsi tape drive we use, so even that has to be
faked.

I re-checked the driver and the Exabyte manual, and my original statement
about being to append at arbitrary filemarks should be correct for 3.3 and
later.  I didn't check 3.2.  Note that this is NOT enough to allow
'tar rvf files' to work, since that requires overwriting data blocks also,
which isn't supported by Exabyte.

--

	Dave Olson

Life would be so much easier if we could just look at the source code.