home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.next.hardware
- Path: sparky!uunet!destroyer!cs.ubc.ca!unixg.ubc.ca!kakwa.ucs.ualberta.ca!news
- From: sherwood@space.ualberta.ca (Sherwood Botsford)
- Subject: Fragmentation & performance
- Message-ID: <1992Nov5.173551.8841@kakwa.ucs.ualberta.ca>
- Sender: news@kakwa.ucs.ualberta.ca
- Nntp-Posting-Host: fenris.space.ualberta.ca
- Organization: University Of Alberta, Edmonton Canada
- References: <Nov.5.01.28.54.1992.15738@gandalf.rutgers.edu>
- Date: Thu, 5 Nov 1992 17:35:51 GMT
- Lines: 26
-
- John Kheit writes
- > The only thing that is a bummer, and its got nothing to do with the
- > drive... is that when you have a drive that big a you move tons of
- > files around the drive starts to get slow because of fragmentation.
- > The kind o fragmentation that just wont go away unless you completly
- > rebuild your drive. I did a rebuild (build disk) and 3.0 now appears
- > to run about 50% faster! I wish that their was somekind of
- > defragmentation software.
- >
-
- Fragmentation doesn't mean the same thing on a Unix file system as it
- does on a Dos file system.
-
- However, if large files are scattered out over the disk, you're right,
- the access goes to hell. I think that the usual reason for this is the
- swap file getting split. If you read through the builddisk script, it
- appears that the writer was very concerned about putting the swapfile
- near the shared libraries. If you ever have to delete the swap file,
- it will be recreated in a different place. If you ever have to extend
- it, the extension will be in a different place.
-
- Try this: Keep track of the largest your swapfile grows during the
- course of normal events. Rebuild your disk, but set it up with that
- size as lowwater, and create that size to begin with. See if
- performance is better.
-
-