news@bbn.COM (News system owner ID) (10/13/89)
stevesc@microsoft.UUCP (Steve Schonberger) writes:
< Another interesting solution, used by Microsoft's announced and maybe
< released OS2 High Performance File System is to use extents (starting
< block, length pairs) as the allocation unit, rather than individual
< blocks. That would be highly inappropriate for Minix though, since it
< is both very un-Unix-like and would require a great deal of rework to
< implement.
Actually, a file system that included extents might not be that hard
to do. Suppose you took the first two block addresses of the inode,
and used them instead for a starting block, num. blocks pair,
_followed_ by the normal block, indirect block, etc. lists. This way,
you could extend a file just like normal (using the normal algorithm),
but also have contiguous block files (a _definite_ speed win) too.
There would, of course, be two problems: there would need to be
a way to collect up a scattered file into a contiguous one (a slow,
and non-standard operation), and the free list handling gets a bit
more complex (perhaps it would need to turn into a free extent list,
with each element listing how many of the following blocks are free,
and a pointer to the next extent).
It would probably be best if such a file system collected files and
free space into a number of track groups, rather than coalescing all
the files to the beginning of the disk. Also, it ideally should try
to place the inode block just before the extent blocks, and all the
files in a given directory together. (In other words, all the standard
high-performance FS tricks.)
The question for Minix, of course, is "Could this be done in a very
small amount of extra code?"
Something like this would certainly help out sub-workstation class
machines, which always seem to have slow disks.
-- Paul Placeway <PPlaceway@bbn.com>