Hi. On my new 3640 box at work, tar(1) seems to run incredibly slowly.
It seems to spend an awful lot of time seeking the tape. Am I doing something
wrong?
Configuration:
Motorla 3640 12 slot VME Box
MVME141 CPU board
MVME2x4 MEM Board
MVME332XT Intelligent SIO controller board (2)
MVME327 SCSI board
CDC WREN IV 300MB SCSI HD
Archive 2150S 150MB SCSI Tape drive
3M DC600A (12500 ftpi) tapes
Motorla System V/68 R3V5
The command I am using is:
$ tar cvf /dev/TAPE.CART files
Thanks in advance
Scott
--
Scott "The Pseudo-Hacker" Neugroschl
UUCP: ...!sm.unisys.com!csun!csuna.csun.edu!abcscnge
-- Beat me, Whip me, make me code in Ada
-- Disclaimers? We don't need no stinking disclaimers!!!
Rating: 0%, 0 votes
Anyway, my group is experiencing some problems in a system with a
Sun 3/280s, a Mercury ZIP array processor, and a Bit 3 VMEbus to
VMEbus interface card (amoung other things).
For some reason the Sun gets a slug of spurrious interrupts after an
interrupt acknowledge by register read on the Mercury ZIP, and we
aren't sure why yet. But one question has come to mind about the
VMEbus RULE 4.5 in our search for an answer: why is there a 2
microsecond specification for releasing the interrupt request line?
Is it a requirement to enable the interrupt handler to discern two
simultaneous interrupts at the same level (while providing a
realistic design time limit)? If there is some other reason, I'd
like to know. We could use all the help we can get.
We have been unsuccessful in triggering our logic analyzer on any
set of signals that would reveal exactly what happens at the instant
the VMEbus fouls up; we just know that hundreds of spurrious
interrupts occur suddently and unpredictably.
Thanks for any help!
Ben Henwood
Applied Physics Lab/UW
b @apl-uw.apl.washington.edu
b @grace.apl.washington.edu
Was this solution helpful? Show your Appreciation by rating it:
Rating: 0%, 0 votes
$ tar cvbf 20 /dev/TAPE.CART files
That way, you specify a larger block size to tar. The only way to get decent
performance with a cartridge tape drive is to keep it running with rather
large blocks. Personally, I use something like:
find files (sorta) -print | cpio -ocvB > /dev/TAPE.CART
The drive seems to keep going pretty well, with few start/stops. Of course,
load on your systems, particularly disk activity, will reduce your ability
to keep your tape drive fed with data constantly.
If you have any further questions, please let me know. I'll help you get in
touch with your local support.
--
Ron Heiby, h @chg.mcd.mot.com Moderator: comp.newprod
"Life is indeed an inexplicable sequence of imponderable surprises."
Was this solution helpful? Show your Appreciation by rating it:
Rating: 0%, 0 votes
use /dev/r41 (minor 4) instead.
Minor 0 tells the driver to do a retension on the tape. Add a 4 to the
minor number (like r41 minor = 4 = 0 + 4) and the tape will start right
away.
Stefan
uunet!asuvax!mcdphx!yendor!stefan
Was this solution helpful? Show your Appreciation by rating it:
Post a New problem for Motorola Expansion Module
Email this problem
Can you Help with these Expansion Modules problems?
inability to operate moulinex...

