Date: Sun, 21 Apr 1996 09:22:49 -0700 (PDT) From: "Jonathan M. Bresler" <jmb> To: dkelly@hiwaay.net (David Kelly) Cc: peter@taronga.com, hackers@freebsd.org Subject: Re: Archive Anaconda on 1540B -- waiting forever for tape to become ready Message-ID: <199604211622.JAA24563@freefall.freebsd.org> In-Reply-To: <v02140b07ad9fd981aeeb@[206.104.22.146]> from "David Kelly" at Apr 21, 96 07:58:08 am
next in thread | previous in thread | raw e-mail | index | archive | help
David Kelly wrote: > > At 10:16 PM 4/20/96, Jonathan M. Bresler wrote: > > is this a brand new blank tape? never before used? > > if so you have to "force" the tape. try "mt -f /dev/rst0 fsf 1" > > for me that results in > > "st0(ncr1:4:0): HARDWARE FAILURE info:1 asc:80,8a" > > but afterward mt operations work! > > I also just installed an Anaconda tape drive but haven't had any problems > like the above. Am running -stable patched thru 0074. Put the tape on ID 6, > my 2G Barracuda is on ID 0. Per Richard J Kuhns > <rjk@sparcmill.grauel.com>'s advice I jumped jp6 (documented as "reserved") > without ever trying it unjumped. jumper 6 is the scsi-1 (open) vs scis-2 (shorted) jumper. > System is a NexGen PCI-90 with Adaptec 2940. > > What bugs me a little is the tape drive doesn't continuously spool during > dump (or tar). Several times it stopped for a second or two. Eventually > dump asked me to insert the next tape. No way, 1.35G tape, 500M fs, I > aborted. Looks like I've got to teach dump how big the tape is, or figure > out how to get dump to run until it reaches the end of tape, or maybe dump > was using 512 byte blocks? be sure to distinguish between the initial tape motions which do some sort of setup activity and the tape motion during data transfer. the drive seeks back and forth several times before it begins to move data. once the data starts moving the drive will stream till (the end of a block ??) and then seek back a couple times. between the seeks there may/will be a short pause. use dump with the 'B' arg for example "/sbin/dump 0unBbf 1200000 10 /dev/nrst0 /dev/sd1a" B - number of dump records per volume (unlimited: 32 bit signed) (a volume is the amount of data you choose to store on each tape, that is B == "number of blocks per file") b - number of kilobytes per dump record (1 - 1000) dump makes some guesses about tape size that date from the days of 9 track tapes. so you have to educate dump about the drive's capacity. > > So for fun I did: "tar -cv /usr /usr1" which is about 1G, and ran to > completion. Then used dd to read the tape to /dev/null and got an > outrageous data rate reported but a sane byte count. This needs more > experimentation. OUTPUT TEST: Aspen:[201] dd if=/dev/zero of=/dev/rst0 bs=1048576 count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 2051 secs (523521 bytes/sec) -- Jonathan M. Bresler FreeBSD Postmaster jmb@FreeBSD.ORG FreeBSD--4.4BSD Unix for PC clones, source included. http://www.freebsd.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604211622.JAA24563>