From: news@ve3ied.UUCP (Owner of news)
Newsgroups: comp.unix.xenix.sco
Subject: Xenix File Fragmenting with News Solved!
Summary: was (Re: Xenix considered harmful)
Date: 14 Oct 92 10:30:37 GMT
Organization: TFMCS

Several weeks ago this thread appeared between Bill Davidsen and Dave Jarvis,
and although it's been awhile, I have something to add.

In article: <1992Sep21.210328.17729@crd.ge.com>, (bill davidsen) writes:
>  Absolutely no opinion here, just facts. If you look at the disk
>fragmentation on any normal usage the xenix system gets worse as time
>goes on. My definition of normal usage is creating and deleting files
>rather than loading files and never changing them. /bin and /usr/bin and
>/lib don't become fragmented, but user files and spool do. and news
>fragments the partition in a few days.

I used to have a problem with fragmentation when I used the standard 2
filesystem setup SCO suggests, (/ and /u).  I used to regularly do a complete
backup and restore to get rid of the 20-30% fragmentation which fsanalyze
reported after only a few weeks.  (I never quite got over the sweating this
would induce, when I trusted the tapes so completely.)

The main culprit was the way cnews interleaves updates to the history files
with the constant creating and deleting of other files.  The "fix" was to
isolate the operations to their own filesystems.  The system is now
"singing" with fragmentation usually a fraction of a percent overall,
and no need to do the dreaded backup/restores.  (I occasionally
shut 'er down to do a "fsck -S".)

The configuration is 340 Meg ESDI, with a small DOS partition.  It's one
of the original 16Mhz 386's (AST).  I am now quite happy with its performance.
(It'll never be a SparcStation which I use at the office, but it's doing
pretty good now thank you.)

Mount Dir   Filesystem  blocks (512K)
------------------------------
/           /dev/root   100000  Binaries etc.  about 75% full
/u/lib      /dev/news    20000  Cnews progs, history, and log files here
/usr/spool  /dev/spool  130000  /usr/spool/news lives here
/tmp        /dev/tmp     20000
/u          /dev/u      301674  users' home, dev't, archives misc catchall

..plus a 10Meg swap which I've rarely ever seen used.  The system hasn't
degraded noticeably at all since!

I get an average of maybe 2Meg of news/day and have a 2 meg history file.
I once used to get discouraged when fsanalyze would show history and logs
being hundreds of fragments only a few days after being "re-organized" with
a backup/restore.  This would of course contributed to other files being
fragmented.  And after a week, it would, as Bill said, be right back where
it started, with maybe 15-20% overall.

I am currently showing the history file as still being the most fractious,
(out of some 15,000 files and directories), but at 20 fragments its far better! 
And I've confined it to one small filesystem.  History.pag is 472 blocks
with only 2 frags after several weeks of nightly expires!  I archive sources
over on the /u catchall directory.

For anyone who wants to attempt this, you have to plan the sizes fairly
carefully.  Leave lots of headroom on the cnews filesystem.  (I have mine
as /u/lib/news and /u/lib/newsbin.  The /usr/lib directory is overworked,
and wouldn't have been possible without including all else in /usr/lib.)
I have mine at about 40% with a 2Meg history file, (14 days).  You may have
to tweak "spacefor" slightly, as it's too conservative for this.  (It needs
space enough to build another copy of history and history.pag)

My spool directory is way oversized, but I will be adding more connectivity
in future.  But it's as clean as a whistle, with nothing over 15 frags, and
mostly in /usr/spool/mail (30 users on dialup).

The easiest way to set something like this up, is to do one final
backup/restore operation, (you shouldn't need to do this again!).
Re-install Xenix as per normal, but when "divvy" comes up, go for
"block by block control".  Modify the defaults by creating the new
"extra" filesystems.

The only other thing to do if you run news, is to use "mkfs" to increase
the number of inodes on your spool directory, because cnews eats them for
breakfast.  (I've used 32K. Of course do this before restoring anything.)
Run "fsck -S" on all the filesystems, (fsck -rr -S /dev/root for the root
partition), and then restore your backups for (hopefully) the last time.
I also set the disk cache buffer to about twice the recommended 600K,
although it's debatable whether this helps much.

If anyone has any questions, let me know.  But as far as I'm concerned,
Xenix can even run news quite happily without file fragmenting!  In fact
any flavour of unix will probably be happier if you split out the offending
file operations which fragment them.


Bill Duncan, (bduncan@ve3ied.uucp -or- ...robohack!ve3ied!bduncan)

PS:  Oh, and Bill, my backups have never been faster!  (Even disregarding
     the fact that I no longer need to do a restore.. ;-)