lkml.org 
[lkml]   [2004]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [IDEA] - run-length compaction of block numbers
From
Date
On Fri, 16 Jan 2004 11:38:59 PST, raymond jennings <highwind747@hotmail.com>  said:
> Is there any value in creating a new filesystem that encodes long contiguous
> blocks as a single block run instead of multiple block numbers? A long file
> may use only a few block runs instead of many block numbers if there is
> little fragmentation (usually the case). Also dynamic allocation of
> inodes...etc. The details are long; anyone interested can e-mail me
> privately.

Only question I have is how you make an efficient scheme for finding the block
number for an offset several gigabytes into the file. You either get to run
through the list linearly (gaak) or you need to stick a tree or hash on the
front to allow semi-random access to a starting point to scan linearly from, at
which point you've probably blown any space savings unless you have a VERY low
fragmentation rate...

On the other hand, dynamic allocation of inodes is interesting, as it means
you're not screwed if over time, the NBPI value for the filesystem changes (or
if you simply guessed wrong at mkfs time) and you run out of inodes when you
still have space free. Reiserfs V3 already does this, in fact...

[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-03-22 14:00    [W:0.067 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site