My orginial question was:
HELP
I just upgraded one of my systems to Solaris 2.4. That machine has a
Exabyte 8500C attached to it. Since the upgrade my backup's are taking
twice as long. I have noticed that I can dump a local 2 Gig filesystem
in about 1.2 hours ( That about what it took under 2.3) however to
dump a remote filesytem that is 1.7 G takes 3 hours. I still have a tape stacker
on a 2.3 machine and the same remote filesystem takes ~ 1 hour.
I have tried all of the following:
Per Technical Bulletin 142.txt from a previous sun-manager FAQ
I updated my st.conf to have
tape-config-list ="EXABYTE EXB8500C","Exabyte 8500c","Exa8500c";
Exa8500c= 1,0x35,0,0xd639,4,0x14,0x15,0x15,0x8c,1;
rebooted the machine with boot -r and had the same results.
Per R-Squared the vendor we purchased the tape stacker from
I updated my st.conf to have
tape-config-list =
"EXABYTE\040EXB\0558500C","EXB-8500C from R Square", "EXB_8500C";
EXB_8500C = 1,0x35,1024,0x1679,4,0x14,0x15,0x8c,0x8c,3;
rebooted the machine with boot -r and had the same results.
I even tried a very old FAQ and patched the driver as follows
> perl -pi.FCS -e s/EXB-8500/EXB8500C/ /kernel/drv/st
> modunload -l 'modinfo|grep -w st | awk '{print $1}'`
Tried the ufsdump and had the same results.
I have been working with SUN but they have not come up with anything yet. They
thought it was the fact that my st.conf was wrong
tape-config-list ="EXABYTE EXB8500C","Exabyte 8500c","Exa8500c";
Exa8500c= 1,0x35,0,0xd639,4,0x14,0x15,0x15,0x8c,1;
They said that the third field of 0 indicated to use 0 block length. But
as I said above I changed that and it did not help.
_______________________________________________________________________________
First I would like to thank
Johnie (js@cctechnol.com), Robert Kohler (robert.kohler@uprc.com), Russ Poffenberger (poffen@San-Jose.ate.slb.com), Stephen Schneider (schneide@scubed.com), and Steve (ssd@nevets.oau.org) for there suggestions.
It turns out that with some help from sun and alot of work on my part
I found the problem. As Stephen put it "I'll spare you the flames that I'd throw at Sun for how they mis-handled my problem and how long it took them to admit the problem was in 2.4." The problem is with a combination of patches.
First, you must have the latest 2.4 jumbo patch 101945-23 and you cannot
install patch 102002 (One of the patches on the CD). Once
I did these two steps my backups now take a reasonable amount of time.
Of course Sun will have to determine whats wrong with that patch.
Thanks for all advise
Jackie Rosinsky
jackie@rentec.com
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:20 CDT