Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.os.misc
Subject: Contiguous files; extent based file systems
Message-ID: <9828@mimsy.UUCP>
Date: 17 Dec 87 01:06:26 GMT
References: <561@amethyst.ma.arizona.edu> <3228@tut.cis.ohio-state.edu> <21545@rebel.UUCP>
Distribution: na
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 35

Personally, I have never cared whether my files were contiguous.  All
I care about is that they be reasonably fast to access.

Completely contiguous files are hard to build.  You must either
declare their size initially or else constantly rearrange disk
blocks.  Contiguous files tend to be fast to access, but if your
OS has a heavy multiuser load, it will often be using several files
at once, destroying the effect created by the contiguous files.

Extent based file systems are usually implemented with a small
maximum number of extents.  This means that the file size must
(implicitly, by extent size) be declared in advance, if the file
may be large.  Many contiguous file allocators actually work with
extents, since this allows a contiguous file to be grown in place.
Many extent based file systems force user code to work with extents,
rather than with bytes; this has a tendency to make programs
inflexible (they deal either with `files' or with `terminals' but
not both).  Some systems solve this fairly well with I/O libraries.

The Unix file interface does not prevent a system from doing
contiguous or otherwise well-scheduled allocation, although it does
make it difficult to declare a file's size in advance.  I consider
this a feature, not a bug: very often I have no idea how big the
file will be.  This facilitates using filters and pipes, where the
input file size is often unavailable.  The 4.2/4.3BSD block allocator
does a fairly good job of arranging the disk, although it uses more
compute power than one would like on, e.g., a Vax 11/750.  Other
allocators exist that also do a good job; the PJW file system in
Research Unix is supposed to work well (I have no firsthand
experience).  All of these manage without leaking the internal
disk organisation out to user programs, which means said organisation
can also be changed relatively easily.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris