NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/software/2913

Internet Message Format | 1992-07-21 | 2.7 KB

Xref: sparky comp.software-eng:2913 comp.arch.storage:524 comp.unix.internals:1579
Newsgroups: comp.software-eng,comp.arch.storage,comp.unix.internals
Path: sparky!uunet!munnari.oz.au!uniwa!DIALix!metapro!bernie
From: [e-mail] (Bernd Felsche)
Subject: Extent-based Filesystems (was: Large Application data sets )
Message-ID: <[e-mail]>
Organization: MetaPro Systems, Perth, Western Australia
References: <[e-mail] <[e-mail]>
Date: Tue, 21 Jul 92 11:36:52 GMT
Lines: 48

In <[e-mail]>
   [e-mail] (Randell Jesup) writes:

>    "extent-based" means that instead of storing lists of blocks, you
>store lists of block ranges (extents).  For example, if you have a contiguous
>file 10MB long, it's stored as starting block and number of contiguous
>blocks (or starting and ending).  As you can see, this is great for storing
>(and seeking) in fairly unfragged files.  It doesn't get worse than lists
>of blocks unless it's average number of contiguous blocks is less than 2.

Understood. The main saving is that each block use doesn't
have to be explicitly named, unless it's at an extent end.
That would save I/O overhead.

>>Does it still allow sparse file?

>    You could design it to do so.  Normally I don't care much about
>sparse files - I think you'll find they don't actually save much on the
>average Unix installation - and some of the uses could be easily replaced.

Ever have a look at core dumps on a Sun? Badly maintained
machines have dozens of 8MB core dumps, though each
fortunately, consumes only a few disk blocks, but they are
fun to backup. (This is admittedly a sick excuse for sparse
files!)

The only rational existence I can think of for sparse files
is with memory-mapped (or similar) data files.

>> Could one still seek to the end of a 256MB file with only 4 block reads?

> You could do it in 0 (on the assumption that the current position's
>file-list block is cached), if the file is reasonably contiguous.  You can
>also combine extents and heirarchical indirection blocks.

If it's cached, UNIX doesn't have to read it either ... but anyway:

Who implements extent-based filesystems commercially? How
does it compare with the alternatives?

I've still to scrape together the money to buy a UNIX
machine where I can write my own brain-damaged filesystem.
Everybody else seems to have done so ;-)
--
+-----+ Bernd Felsche                     _--_|\  #include <std/disclaimer.h>
| | | | MetaPro Systems Pty Ltd          /      \ [e-mail]
| | | | 328 Albany Highway,              X_.--._/         Fax: [phone]
|m|p|s| Victoria Park, Western Australia 6100  v        Phone: [phone]