Path: utzoo!utgpu!water!watmath!clyde!burl!codas!killer!fmayhar
From: fmayhar@killer.UUCP (Frank Mayhar)
Newsgroups: comp.os.misc
Subject: Re: Contiguous files; extent based file systems
Message-ID: <2740@killer.UUCP>
Date: 9 Jan 88 08:49:22 GMT
References: <561@amethyst.ma.arizona.edu> <3228@tut.cis.ohio-state.edu> <177@cullsj.UUCP> <1931@rti.UUCP> <517@usl-pc.UUCP> <12210@orchid.waterloo.edu>
Reply-To: fmayhar@killer.UUCP (Frank Mayhar)
Distribution: na
Organization: The Unix(R) Connection BBS, Dallas, Tx
Lines: 31

In article <12210@orchid.waterloo.edu> atbowler@orchid.waterloo.edu (Alan T. Bowler [SDG]) writes:
>The real thing is that a extent based system requires a reasonably
>regular file system maintenance proceedure to "compact" multi-extent
>files into a single extent, so the user doesn't have to worry about
>this.  One approach is to simply dump restore the whole file
>system once every few months.  [...]
>   There are real advantages to extent based systems, but like
>everything else they do not come for free.  In this case there
>is a lot of work required to do a "complete" implementation job.
>Incomplete extent base systems seem to work for a while, but
>a user feel like he has hit a brick wall when he runs into
>a restriction imposed by an inncomplete implementation.

Just out of curiousity (I "own" the file management part of an OS that uses
an extent-based file system), exactly what do you mean by a "complete" 
implementation?

The OS I work with (and help maintain) is the Honeywell (Bull) CP-6 Operating
System.  Your remarks (quoted above) regarding file fragmentation are right on
the money in our case.  It's even worse because the only way we have to
effectively de-frag our disks is to do a ful backup/restore, since the level of
abstraction we provide at the user level prevents us from having a program
(that's not actually part of the OS itself) from working with the disk
directly.  Not to mention the fact that having a program moving extents around
would play hell with our disk I/O caching scheme.  (Nothing like having a file
directory page in the middle of a FORTRAN source file. :-)
-- 
Frank Mayhar        UUCP: ..!{ihnp4,dj3b1}!killer!fmayhar
                    ARPA: Frank-Mayhar%ladc@BCO-MULTICS.ARPA
                    USmail: 680 Grand Ave #201 Long Beach, CA 90814
                    DeathStarNet: (213) 438-7899