stevedc@syma.sussex.ac.uk (Stephen Carter) (04/30/91)
Disc Fragmentation (etc) ------------------------ Operating systems I have dealt with in the past (eg RSTS, MS-DOS, VMS) have all had a range of utilities that address the twin problems of disc/data file fragmentation and directory tidying up. Functionally un*x seems to be the same as all of these (don't flame me!) in that users make and delete files, and that in time the data blocks that together make up the files can be all over the disc - presumably leading to inefficiencies. Yet I have not heard of any utilities to reorder un*x directories or to defragment discs. Is there a reason? (Reasons such as un*x is 'better', or that un*x machines are so fast that these performance issues don't matter will be carefully consigned to /dev/null and read next year). Stephen Carter, Systems Manager, The Administration, The University of Sussex, Falmer, Brighton BN1 9RH, UK Tel: +44 273 678203 Fax: +44 273 678335 JANET: stevedc@uk.ac.sussex.syma EARN/BITNET : stevedc@syma.sussex.ac.uk UUCP: stevedc@syma.uucp ARPA/INTERNET: stevedc%syma.sussex.ac.uk@nsfnet-relay.ac.uk
src@scuzzy.in-berlin.de (Heiko Blume) (05/01/91)
stevedc@syma.sussex.ac.uk (Stephen Carter) writes: > Disc Fragmentation (etc) for system V machines: i regularly use a program called packdisk on my /usr/spool/news. another program called fsanalyze tells me that the above filesystem takes about two weeks to develop >40% fragmentation. packdisk makes that ~3% again. packdisk was posted to comp.sources.misc, volume8, fsanalyze is in volume5. of course packdisk is somewhat dangerous :-) -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 [voice!] public UNIX source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
brtmac@maverick.ksu.ksu.edu (Brett McCoy) (05/02/91)
In <1991May01.154043.1031@scuzzy.in-berlin.de> src@scuzzy.in-berlin.de (Heiko Blume) writes: >stevedc@syma.sussex.ac.uk (Stephen Carter) writes: >> Disc Fragmentation (etc) >for system V machines: >i regularly use a program called packdisk on my /usr/spool/news. >another program called fsanalyze tells me that the above filesystem >takes about two weeks to develop >40% fragmentation. packdisk makes >that ~3% again. packdisk was posted to comp.sources.misc, volume8, >fsanalyze is in volume5. of course packdisk is somewhat dangerous :-) One reason such a tool doesn't exist for BSD 4.2 filesystems is that it is built in to the filesystem. The 4.2 filesystem does it's best to keep a disk from fraging, and to unfrag a disk that is fragmented as files are read and then rewritten. The 10% diskspace buffer that is suggested for filesystems is to allow the extra space with which to perform this task. If you cut the buffer down to 0% and then fill the disk up it will fragment rather badly, but so long as you leave the 10% free space you will usually never get more than 3-4%. On my news partition the worst I have ever seen it get is 4% after months of use. -- Brett McCoy Computing and Telecommunications Activities brtmac@maverick.ksu.ksu.edu Kansas State University Every woman's a 10. It just depends upon which base you're counting in.
pb@idca.tds.PHILIPS.nl (P. Brouwer) (05/03/91)
In <1991May01.154043.1031@scuzzy.in-berlin.de> src@scuzzy.in-berlin.de (Heiko Blume) writes: >stevedc@syma.sussex.ac.uk (Stephen Carter) writes: >> Disc Fragmentation (etc) >for system V machines: >i regularly use a program called packdisk on my /usr/spool/news. >another program called fsanalyze tells me that the above filesystem >takes about two weeks to develop >40% fragmentation. packdisk makes >that ~3% again. packdisk was posted to comp.sources.misc, volume8, >fsanalyze is in volume5. of course packdisk is somewhat dangerous :-) This program has one disadvantage: It reformats the disk with a mkfs gap size of one. For most scsi disks this is okee but for ESDI this might result in a slow down of the diskthroughput. fsanalyze used the gap value from the superblock which is set to one by packdisk. So you will not notice it. If you are not sure if this is the correct gap value for your disk find a spare partition. Execute a mkfs with a gap of 1 . Use the bonnie disk benchmark to measure the disk throughput. Do this sequence for different gap sizes. The diskthrough put for sequential IO should give an optimum somewhere. -- # Peter Brouwer, | Philips Information Systems, # # NET : pb@idca.tds.philips.nl | Department P9000-i Building V2, # # UUCP : ....!mcsun!philapd!pb | P.O.Box 245,7300AE Apeldoorn,The Netherlands# # PHONE:ext [+31] [0]55 432992, | FAX :ext [+31] [0]55 433488 #
jar@ifi.uio.no (Jo Are Rosland) (05/12/91)
In article <1991May2.024639.9011@maverick.ksu.ksu.edu> brtmac@maverick.ksu.ksu.edu (Brett McCoy) writes:
One reason such a tool doesn't exist for BSD 4.2 filesystems is that
it is built in to the filesystem. The 4.2 filesystem does it's best
to keep a disk from fraging, and to unfrag a disk that is fragmented
as files are read and then rewritten. The 10% diskspace buffer that
is suggested for filesystems is to allow the extra space with which
to perform this task. If you cut the buffer down to 0% and then fill
the disk up it will fragment rather badly, but so long as you leave
the 10% free space you will usually never get more than 3-4%. On
my news partition the worst I have ever seen it get is 4% after months
of use.
When you talk about fragmentation percentages here, do you mean the
output from fsch when booting? Well, that's not a measure of
fragmentation as the original poster meant it. The thing is, under
4.2BSD file systems, you've got something called "fragment blocks",
and the "frags" percentage from fsck is just the percentage of data
blocks that are used as fragment blocks. It's not a measure of
fragmentation at all.
--
Jo Are Rosland
jar@ifi.uio.no