Von Braun: "Research is what I'm doing when I don't know what I'm doing."

In the Trenches with LAROKE

Konsultant's Log, Cyberdate 09.13.1997 (A tune-up for Old Blue)

SITREP: On the network PC's I maintain at my daytime job I perform disk drive maintenance at regular intervals, generally at the rate of one machine a week. Since there are ten computers in the network, each machine receives disk maintenance once every ten weeks "in a perfect world". This work is a drudge, but necessary. Old Blue, the file server, is the first PC in the cycle. The last time we gave Old Blue this much attention was in the first two installments of In the Trenches (see In the trenches Cyberdate 08.06.1996 "upgrading the file server Old Blue" and In the trenches Cyberdate 12.19.1996 "Restoring the file server "Old Blue"). This time, as then, Old Blue's maintenance would be anything but routine.

TACAMO: Just before Old Blue's scheduled maintenance, I'd noticed that the CAD workstation known as "Three-Dee" was very close to an "out of diskspace" error on his hard drive. As soon as I detected this potentially-catastrophic situation, I mentioned it to Jay, the "kewl" guy from California, who is in charge of Three-Dee. Jay is geared for speed, not comfort, so he sometimes lets the "dirty laundry" chores like file management pile up.

Jay responded by dumping a whole "pile of stuff" on Old Blue for archival (over 500MB!). Sorting through this stuff was like rooting around in a dumpster. It took me over six hours on a Friday night and the following Saturday morning to "separate the wheat from the chaff", cursing Jay every half hour or so. He had ZIP files within ZIP files up to three levels deep. He had many copies of the same file in different subdirectories and in the ZIP files as well. All files had to be unzipped and duplicates eliminated. When I stated 500MB above, I meant after the cleanup! For a while, I entertained the idea of "short-sheeting" the diskspace on Three-Dee, so Jay couldn't do this again, but settled for giving him one of my famous "Dutch Uncle" lashings instead.

Old Blue also requires the most work due to the fact that it has two physical SCSI drives with three Stacker compressed drive volumes for a total of 5 drive designations, C: through G: and a capacity of 6GB of diskspace.

I had to move several drawing file directories from one compressed drive to another, due mainly to the 2GB maximum size of a Stacker compressed drive. File maintenance with this storage strategy is becoming somewhat unwieldy. I'm beginning to investigate construction of a new server with the new Windows 95 FAT32 file system that allows bigger drive partitions and reduces the need for compression technology. This strategy would also require an investment in a new higher capacity tape backup system.

During the file management operations on Old Blue I ran face-first into a new konundrum:

KURRENT KONUNDRUM #2

8:30 AM 8/23/97 System 04 Maintenance (Old Blue): Started file maintenance but Windows Explorer started to act up by causing fatal exceptions when trying to delete directories. Performed a warm reboot but problem remained. I shutdown "Old Blue" for thirty seconds for a cold bootup, what NASA calls "recycling the system". Again the dreaded blue screen fatal exception error "A fatal exception 0D has occurred at 0028:c0002840 in VXD VMM(01) + 00001840. The current application will be terminated." Old Blue was warm booted again and a thorough SCANDISK test was initiated on Physical drives C: and D: SCANDISK did not find problems with either drive. The problem remains so the next step is to check the Stacker compressed drives (the files I'm trying to delete reside on a Stacker drive). SCANDISK would not run on the Stacker compressed volumes from within Windows 95, so Stacker's Check utility was run on compressed volume C:. It found cross-linked files and recommended running CHKDSK with the /F parameter from the DOS command prompt outside of Windows. This recommendation does not give me the "warm fuzzies" as CHKDSK is not entirely reliable in the /F mode (Fix). After rebooting Old Blue to the DOS Command Prompt, I decided to try SCANDISK one more time on the Stacker volumes, this time outside of Windows 95. Much to my relief, it worked and fixed the cross-linked files on compressed drive C:. No problems were reported for the other two Stacker volumes on Old Blue. Now it was time to run Stacker's Check utility on those two volumes. Stacker did not detect any problems with the compressed drives, and the fatal error in Windows Explorer on Old Blue persists. This condition may not be a new development, since I do most of the file management on Old Blue from other machines on the network. At this point I tried the command that was locking up Old Blue from Windows Explorer on P2, my old workstation. No problemo! Windows Explorer on P2 deleted the directory on Old Blue across the network with no "burps" from either machine. Next, I downloaded the latest anti-virus signature update file for PC-cillin95 from their Website and virus-scanned the five drives on Old Blue, just in case. The drives were all clean. Anybody who has experienced this dreaded blue screen of death with Windows Explorer and knows how to fix it, give me a shout if you can.

KURRENT KONUNDRUM #2 UPDATE

02.17.1999 This Konundrum is no longer an issue. It has been placed in solution category 4 (new technology renders the problem academic and solution is abandoned). During Old Blue's refit as a communications server, the Windows Explorer malfunction completely disappeared. See "Old Blue becomes the Old Guard" Parts I, II and III.

REPLY TO THIS S.O.S.? email address (required) Name (optional) Enter your comments below

After file management on the 5 drives had been completed, a full backup was performed on Old Blue. The Hewlett-Packard Colorado PD60 Datastor DAT tape subsystem we have connected to the network through Old Blue has a capacity of 4GB per tape (compressed). This unit has been a good, reliable backup drive. Compared to the klunky, OIC/TRAVAN technology, It is nothing short of wonderful.

I schedule backups to run overnight. Since Old Blue has grown to over 4GB in files to process, I have arranged his full backup into two backup filesets: A full backup of physical drive C: including it's Stacker compressed volume the first night and a full backup of physical drive D: and it's two Stacker volumes on the following night. Even though the tape backup software is capable of "spanning" several tapes in a backup session, I prefer to keep backup sets at the size that will fit on one tape, so that a backup set can be completed without human intervention (changing tapes when prompted by the backup software "gets old fast").

INTSUM: One of the other procedures I perform during system maintenance is running diagnostic reports from the various utility programs I use, and putting these reports in a safe place with the other system documentation, in the hope it might be helpful in fixing any future system "meltdown".

8:56 AM 8/30/97 Old Blue Maintenance: Ran System Resource Report for Old Blue. For those of you with Windows 95 who are not aware of this feature, the following instructions will show you how to run this report on your own systems. This report gives you a System Summary, IRQ Summary, IO Port Summary, Upper Memory Usage Summary, DMA Usage Summary, Memory Summary, Disk Drive Info, and Extensive System Device Info.

It's good to run this report from time to time and file it with your computer documentation. It is especially appropriate to print this report after installing new hardware. Even if you don't understand much of the terminology of the report, it may be of help to a technician trying to fix your PC if it needs repair.

To run this report, you first right-click the "My Computer" icon on the Windows 95 Desktop and choose the "Properties" item from the resulting context-sensitive menu. This produces the "System Properties" dialog window. Click the "Device Manager" tab and click the "Computer" item at the top of the list window, if it isn't already highlighted. Now click the "Print" button below the list window. In the resulting dialog, click the "All devices and system summary" radio button. Click the "Setup" button to make any adjustments in your printer setup, if necessary. Click the "OK" button when you're ready to print. That's all there is to it. The report will be seven or eight letter-size pages long on a lightly-loaded system without many devices.

RECCEXREP: The standard disk maintenance for Old Blue was complete. I determined to "optimize" one of the Stacker drives since I had never done this before and it might yield some additional diskspace on the subject compressed drive which had 86% of its capacity used at this point. This process turned out to be more fun than "a sharp stick in the eye".

5:48 PM 8/25/97 After the office had quieted down for the day. I rebooted Old Blue, the file server, in DOS mode to run the Stacker Optimizer Utility on the Compressed drive G:. I opted for the "Maxspace" setting, since we are beginning to run out of space on Old Blue and I wanted to see if the performance "hit" was noticable in everyday operations.

This is a long process, and improper exit from the program could cause damage. I crossed my fingers because I planned to let it run overnight. Short power interruptions would not be a problem since Old Blue is protected by an UPS (Uninterruptable Power Supply), but if the power went out for more than twenty minutes, I would be in trouble.

I returned the following morning to find the Stacker Optimizer reporting a "Fatal Error, not enough memory" message. After rebooting, bringing up the Stacker Toolbox revealed that 2% of the compressed drive's space had been recovered before the fatal error occurred.

The following night I tried the same process from the "Safe Mode Command Prompt" with the belief more conventional memory would be available without the startup drivers loaded. This was a mistaken assumption on my part since the memory managers are included in the unloaded drivers and, as a result, even less memory is available.

Reviewing the Stacker manual, I found that if I ran the Optimizer at the Command Prompt by typing the Command

C:\>SDEFRAG /buffer=256

I could save 78.75KB of conventional memory required to run the Optimizer. This was done for the next test run. I still received the now-dreaded "out-of-memory" fatal error.

Rooting around in the "Windows 95 Resource Kit", I discovered that MS-DOS 6.2 memory management could be used in Windows 95 to "tweak" the AUTOEXEC.BAT and CONFIG.SYS files and that the MS-DOS 6.2 MEMMAKER utility could be run. MEMMAKER is not installed with Windows 95 (all MS-DOS command files in Windows 95 are installed in the "\WINDOWS\COMMAND" subdirectory and the MEMMAKER files were not there).

MEMMAKER is provided, however, with the Windows 95 CD. The MEMMAKER files are located in the "\OTHER\OLDMSDOS" subdirectory on the CD. I copied the MEMMAKER files from the CD to the \WINDOWS\COMMAND directory on Old Blue and restarted Old Blue in Command Prompt mode.

I ran MEMMAKER successfully and gained 38KB of conventional memory for a total of 548KB conventional memory. Running SDEFRAG with the /buffer=256 parameter should have given me a comfortable margin over the 600MB of conventional memory the Stacker manual says is required to run the Optimizer, but it didn't. I still got the acursed "out-of-memory" error!!

Memory can be further optimized "by hand", but that would require an investment of time for research and experimentation that I just don't have currently. The latest version of QuarterDeck's QEMM Memory Manager for Windows 95 is another possibility.

The problem is I'm beginning to get the uncomfortable feeling that the "out-of-memory" error message is not reporting the true problem here, and that memory has nothing to do with the malfunction that is stopping the Stacker Optimizer "in it's tracks". I've seen a lot of error messages, and I've been lied to by the best!

I decided to visit the Stacker Web site before giving up for now since I hadn't been there for some time. In the technical support area I found specific instructions for getting around this problem, including the statement that I might need as much as 620MB for the larger compressed drives.

I commented out all the lines in the CONFIG.SYS file and entered the exact lines recommended, then followed their instructions for bootup and running SDEFRAG (with the /buffer=256 parameter). This gave me 571KB conventional memory at the Command Prompt. Subtracting the 78.75KB savings of the buffer parameter from the required 620KB equals an estimated 542KB needed by the Optimizer (almost a 30KB safety margin). If it doesn't work this time, my suspicions that memory isn't the real problem will be strengthened.

Well, this time it worked...kinda. With the low buffer setting, at the end of an hour of optimizing time, the job was 0.5% complete! At this rate it would take over 8 days to optimize the drive, and Old Blue would be inaccessible to other PC's on the network during this time. Since Old Blue is the main file server, this is not an acceptable solution.

I decided to exit the Optimizer and start it again at the end of the day to run overnight. I wanted to see if the Optimizer would pickup where it left off or start over from the beginning. Later in the day when I re-booted Old Blue to run the Stacker Optimizer Overnight, I somehow came up with 623KB of conventional memory at the Command Prompt, so I decided to risk running SDEFRAG without the buffer parameter.

When I came in the next morning, It had optimized 4.4% of the compressed drive in 14.5 hours of runtime (poorer performance than with the minimum buffer parameter), and the defragmentation level had climbed from 7% to 9%! The next night when Old Blue again booted with 623KB of conventional memory I tried a buffer parameter of 3072 to see if I could get a better speed rating, than the default buffer of 4096. The results were even more disappointing: 4.2% of the drive had been optimized in 13.5 hours, and the optimizer starts at the beginning every time it is run.

MISREP: Old Blue's disk drives are in pretty good shape now, but the Stacker drive optimization experiments were a big disappointment. It would take much less time to backup the compressed volume I want to optimize, delete the compressed volume, defragment the physical drive that the compressed drive was on, create a new compressed volume, and finally restore the compressed volume data from tape. That seems like a lot of unnecessary work to me, and there are even more steps involved if the drive you want to optimize is the compressed volume on which the operating system files reside. I think I'm going to advance my new server project planning up a notch to DEFCON 3 (DEFense CONdition 3).

LAROKE Microcomputer Consultants
155 East Boca Raton Road
Boca Raton, Florida 33432
(561)368-0659 (Tel & Fax)

Issued Saturday September 13, 1997

Updated Wednesday March 3, 1999

copyright © 1997-1999 LAROKE Microcomputer Consultants all rights reserved

Search www.laroke.com the Web for