Date: Sun, 8 Dec 96 21:38:24 -0500 From: curt@kcwc.com (Curt Welch) To: Jeff Aitken <jaitken@dimension.net> Cc: questions@freebsd.org Subject: Re: HP T4000s tape drive Message-ID: <9612090238.AA06537@mail.kcwc.com>
next in thread | raw e-mail | index | archive | help
> I recently purchased an HP T4000s "Colorado" SCSI-2 tape drive Me too. I have two of them on FreeBSD boxes. Also running 2.1.5R > I'm a little unsure just how I should invoke, e.g., > dump(1) to have things work "optimally". If I specify > no arguments at all, like this: > dump 0uf /dev/nrst0 /home > then I get nowhere near the advertised capacity (the tape > "fills up" after only a few hundred MB's). So, I gather > I need to specify the density and length of the tape (via > the 'd' and 's' options, respectively). > Is it as simple as: > dump 0udsf 67733 740 /dev/nrst0 /home > or not? I presume that the "bit density" the manual > mentions is the bits per inch (BPI)? The tapes claim to > be 740ft (225.6m) in length. Don't waste your time with the d and s options. Dump uses a complex formula for mapping those numbers into what it thinks the tape will hold in terms of blocks. Use the newer and better B option. (I don't known when this got added, but FreeBSD was the first system I saw this on.) With B, you just specify how many blocks the tape can hold, a much cleaner way to do things. However, It's unclear to me if these "blocks" are 1K or 8K, or the size specified by b. I would assume they were the size specified by the b option, but some testing I did made me wonder if this was correct. > Just for fun, I've experimented with a variety of > different density/length values, none of which satisfy > me (yet). Using the above-mentioned values doesn't even > come close, so I've obviously missed something. Yes, what dump does with the d and s numbers is a mystery (unless you read the source). > I figure I must be missing something, since my drive > hardly "rips right along". I'm seeing between 100 and > 300 KBps during backups, far from the advertised 514KBps > (which, no doubt, only occurs under "optimal" > circumstances, like when using the HP-provided software > under an HP-supported platform :-) :-) Yes, I too had the same problem. A test program to fill the entire tape up took over 8 hours to run which works out to about 7.5 Meg/minute (or 122KBps). The trick I found was to use block sizes of at least 15K. I now normally use 32K blocks. Once you do this, the drive can stream (write without pausing and backing up). My test program was then able to fill the tape in 2 hours and 21 minutes. This works out to 27.9 meg/minute (476KBps). BTW, my test program wrote 126042 blocks of 32768 bytes for a total tape size of 4130144256 bytes, which is 3.9 Meg in 1024^2 terms. For dump, I'm using options like this: dump 0ubBf 32 1200000 /dev/nrst0 /dev/some-disk Since I put multiple backups on a single tape, the only thing important about the B number is that it's large enough to keep dump from stopping too soon. I have some questions about these drives (and the st driver) also. When the system boots, I get: ahc0:A:4: refuses syncronous negotiation. Using asyncronous transfers (ahc0:4:0): "HP T4000s 1.06" type 1 removable SCSI 2 st0(ahc0:4:0): Sequential-Access density code 0x0, drive empty Is this message about refusing sync[h]ronous negotiation normal for SCSI tape drives? Is it normal for this drive? And every time you access the drive when it's rewound, I get the kernel message: st0(ahc0:4:0): ILLEGAL REQUEST asc:20,0 Invalid command operation code Can anyone tell me what's causing this? It doesn't seem to be a problem but it bugs me and I'd like to find a way to get rid of the message. I assume the st driver is sending some type of command to the drive that it's rejecting. Can anyone tell me what it might be trying to do or how I might go about figuring this out? And two or three times, I've gotten: st0(ahc0:4:0): timed out in dataout phase, SCSISIGI == 0x0 st0(ahc0:4:0): BUS DEVICE RESET message queued. Bus Device Reset Message Sent st0(ahc0:4:0): Bus Device Reset delivered. 1 SCBs aborted ahc0:A:4: refuses syncronous negotiation. Using asyncronous transfers When this happens, the drive stops working until I reboot. Any advise on what might be causing this and what might be done about it? Curt Welch curt@kcwc.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9612090238.AA06537>