Text 307, 96 rader
Skriven 2006-10-13 15:45:44 av Mike Luther (1:117/3001.0)
    Kommentar till text 306 av Sean Dennis (1:18/200.0)
Ärende: disaster with Linux
===========================
Sean  .. and others here...

 SD> I just bought an internal SCSI DDS-2 4/8GB DAT drive and am waiting for 
 SD> tapes I ordered (found them for $2.47 a piece off the 
 SD> Web) to arrive today.  It's recognized by BA/2000 and 
 SD> all seems to be well.  We'll see once I make a backup. 
 SD>  It'll be nice to have my butt covered in case 
 SD> something goes wrong with this machine (although I 
 SD> seriously doubt it).

I'll give you all a hint when using BA/2000 with SCSI hard disks and SCSI 4MM
DAT tape drives.  I've been using BA/2000 Server Pro for years here as well as
some clients have been using it as well this way.  In my case the tape drive of
choice started out with the Seagate 12GB tape unit, but we outgrew that one
pretty rapidly.  I'm using the Seagate 24GB units now .. I guess that's QUANTUM
or whatever has happened to the whole thing that has rippled in from the
Seagate acquisition and shuffle game.  That's not important.

What is important is that you have to be very careful about how you set up the
Adaptec controller card firmware for this job.  One of the reasons to use the
Seagate tape units is that they can have the interface set exactly to the same
profile that you are using for hard disk units tied to the board.  Be very
carefull to get that synced right.  If you use Sync operations with your hard
disk you HAVE to use a tape drive that can handle this, which the Seagate
drives can do.

One of the key issues with the BA/2000 code is that this utility uses 'long
writes' for the tape storage operations.  That's not necessarily thought out
too well by OS/2 and Adaptec and whatever for some versions of this and that ..
considering CPU speed, memory and so on.  If all you are doing is working with
about half the tape total storage ability and say less than 100,000 or so
files, you may never see a real strange hard lock drive issue with BA/2000. 
But as the total backup compressed size gets on up toward the fill point for
the tape drives, and you get way up there into the 150,000-250,000 file count
range .. poof!  You'll see odd issues where the whole system will freeze hard
red light on locked.

The slush stuff for the tape utility for the hard disk directory organization
in the \TEMP directory will get slammed into \FOUND0 on whatever partition it
is on after the hard three finger salute to recover the box.  And this goes on
for whatever.

Here is the solution I have found seems to work.  First, before any backup I
use the Gammatech Utilities HPFS Defrag utility for OS/2.  I do a three pass 3
extent cleanup of the whole partitions for the whole box prior to the backup. 
Of course I do a complete CHKDSK of all the partitions and I also do a complete
UNIMAINT .INI file cleanup and whatever.  Only then do I reboot the box to a
virgin start.

At that point I do something else very different.  From the command line in an
OS/2 window session, I turn off the HPFS write cache with the following command
line:

            cache \lazy:off

Only then do I put in the new backup tape.  I do an initialization for the tape
by hand before the backup.  Then I do the entire easy standard whatever I've
chosen master backup routine for the box.  I've found that I can seemingly
prevent this long sector SCSI write error gambit on these big boxes and tape
drives with this trick.

After the backup finishes, then I check to make sure all the temp files are
gone and things are stable.  I then reboot the whole box to regain the HPFS
cache lazy write standard default operations.

Of note, I've also found out that if you are using constant all four port
serial port operations, SIO for Telnet, and TCP/IP on a box with lots of BBS
operations at work as well, for some operations prior to FixPack 16/17 with
Warp 4, you'll see strange lockups as well.  A whole round of debug went into
fixing this with IBM formally on TestCase prior to the FixPack 16 level on Warp
4, the needed changes in DHCP code, and so on both for Warp 4 and MCP1/2 here
over all this.  I don't see this issue about HPFS write cache failures any
longer with the current level code for the boxes, so it was fixed by IBM.

But the trick to turn off HPFS lazy write for hard work long sector 64K chunks
that BA/2000 uses, that I'm told very few other programs use,isn't well known I
suspect.  Another program which seems to use this is the Norman Virus 5.8 level
code.  You'll see these long sector operations put on the hard disk activity
light BRIGHT RED for long periods of time when it is in use, as best I know
this.  Norman's command line virus check does this when checking inbout Email
on Post Road Mailer messages and attachments too.  And .. it .. too, at rare
times, when you are working with Seamonkey, Java and whatever, can sometimes
jam lock a box during the virus scans this same way.  But I've never tried the
lazy write turn off fix yet to test this,


Whatever ...


--> Sleep well; OS/2's still awake! ;)

Mike @ 1:117/3001


--- Maximus/2 3.01
 * Origin: Ziplog Public Port (1:117/3001)