OT: SCO Drive Performance issue

[GCC Consulting]

> > 
> > I would be very surprised if disk fragmentation were causing 
> > performance issues on SCO OpenServer systems, particularly in a 
> > production environment such as a business/accounting system.
> 
> Ok. Be surprised.
> 
> > This type of system typically doesn't create/delete large 
> numbers of 
> > files which might lead to fragmentation.  Even in 
> environments such as 
> > development machines where one is continually building 
> software which 
> > well create thousands of temporary files, I've never seen any 
> > significant fragmentation since the days of SCO Xenix, and I don't 
> > remember this being a major problem even then.
> 
> filePro fragments filesystems easily. Files and indexes, open 
> concurrrently, literally leapfrog each other on the hard 
> drive as records are added.
> > 
> > Back when we were running usenet news servers on OpenServer, there 
> > were frequent issues with inodes disappearing which would require 
> > unmounting the file systems to run full fscks so that the 
> inode counts would be correct.
> > This wasn't an issue of fragmentation, but bugs in 
> OpenServer at the time.
> 
> All I have to do is perform a disaster recovery on my primary 
> server periodically and my access times go down. Sometimes my 
> full system backups increase in speed by 150MB/min as the 
> hard drive has less work to do to get the data streamed out 
> to the tape.
> 
> My primary server runs filePro for invoicing, and filePro for 
> registration, and old fashioned RealWorld / Great Plains for 
> accounting, plus file sharing.
> 
> Even the most optimized OpenServer 5 filesystem, however, 
> can't keep up with modern filesystem caching.

I'll put my 2 cents in here even though its been years since I have been on
a *nix system.

If you are finding fp fragmenting files too much, expand you active files by
adding enough records to cover a reasonable time period of use for the size
drives you have.  After you have done this, then do you backup and restore.

If you really wanted to be anal about this, one could to a file by file
restore, placing all of you master files, which usually aren't updated a
lot, first, then adding back those files which are added to the most.  One
advantage to this is faster access to those master files as the head travel
is less.

Of course, this is an "old" technique but it does work.

On my Windows based systems using Norton speed disk, I can accomplish this
with ease and no restore. :)

Richard Kreiss
GCC Consulting