Path: utzoo!attcan!uunet!lll-winken!lll-ncis!helios.ee.lbl.gov!pasteur!agate!bionet!csd4.milw.wisc.edu!leah!bingvaxu!sunybcs!rutgers!att!ulysses!andante!alice!debra
From: debra@alice.UUCP (Paul De Bra)
Newsgroups: comp.unix.questions
Subject: Re: File Fragmentation
Message-ID: <8725@alice.UUCP>
Date: 11 Jan 89 00:44:32 GMT
References: <18068@adm.BRL.MIL>
Reply-To: debra@alice.UUCP ()
Organization: AT&T, Bell Labs
Lines: 33

In article <18068@adm.BRL.MIL> slouder@note.nsf.gov (Steve Loudermilk) writes:
}Hi,
}
}I am involved in a local discussion about the benefits of "compacting" the
}information on our disks regularly.  By compacting I mean dumping to a
}different device, running "newfs" and then restoring a file system.
}
}One school of thought says this is necessary and should be done fairly
}frequently to avoid excessive fragmentation and inefficient disk I/O.
}
}The other school of thought says it isn't necessary because of the way 
}the Berkeley "fast file system" (BSD 4.2) handles assignment of
}blocks and fragments when a file is stored.  
}

Disk fragmentation (or file-fragmentation as you call it) still occurs
in most versions of Unix, but the Berkeley "fast file system" keeps it
to a minimum.

On a BSD system I would think that a dump/newfs/restore should be done
every year or so. On other systems the file system can be messed up in
a matter of hours, but one (painful) solution is to unmount and fsck -S
all file systems once a day, and then one can keep the fragmentation
down for a long time. The old file system does not try to use the disk-
blocks in any sensible way. It keeps a queue of blocks being freed and
reuses them in that order. The V9 "bitmap" file system keeps fragmentation
more local although it doesn't keep it down quite as much as BSD I believe.

Paul.
-- 
------------------------------------------------------
|debra@research.att.com   | uunet!research!debra     |
------------------------------------------------------