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