Ignatios Souvatzis wrote:

> > It might be nice too to change the Ifile to address these inodes by disk
> > blocks instead of by fs blocks.  That way, we can avoid searching an
> > entire
> > inode block for each inode.  And perhaps as an extension of this idea,
> > we could
> > eliminate inode 'blocks' altogether and just have a field in the segment
> > summary describing how many inode disk blocks immediately follow the
> > summary.
> 
> Hm, using fs blocks has the benefit that this scales with the fs
> block (I guess, fragment?) size, so BIG partitions have a chance to work...
> or am I wrong?

True, though we already address most every other kind of block on LFS
with 
512 byte disk blocks.  Assuming 32bits address for 512 byte disk blocks,
the
theoritical maximum filesystem size would be 2047 Gb.  However, this
limit
might come sooner on media with a smaller block. (if there is such a
one)

At any rate, even fragment addressing would be better than the current 
full fs block addressing for inode blocks. Though even with this, we
would 
have to change other things that depend on db addressing for this to do
us 
any good for >2047 Gb filesystems.  

I guess that unless we're going to make the change to do fragment
addressing in LFSv2 disk blocks would be better and more consistant with 
the rest of the FS, but if we do decide to make the db --> frag
transition 
now, frag sized inode blocks would probably be better.  I am starting to 
think that maybe we should commit to the listed 'nice to have' db ->
frag 
addressing change for Lfsv2. Konrad, I'd implement this if you agree. 
I'd 
also actually like to see the rest of the 'nice to haves' either
abandoned
or committed to for LFSv2. Granted, LFS is still an 'experimental' file 
system of sorts though I still don't think users would appreciate
knowing 
they might have to rebuild their LFS's for a 3rd revision of LFS
sometime 
in the future. :-)  The "Get it Right The First Time" NetBSD slogan,
right?

Note too that there isn't much advantage to using anything but a 512
byte 
fragment size in LFS other than the potential for increased
addressability
(which doesn't exist in the current LFS incarnation because everything
is
disk block based) and maybe in some esoteric usage scenarios I can't
think
up right now.  (correct me if there are any obvious ones).  Maybe it
would
be worthwhile to have fragsize computed (not specified) at fs creation
time
based on if the filesystem is >2047Gb or not.  Otherwise, fragsize could
== disk block size.  

Back to the original point: I'm not sure I'm convinced we need to make
inode 
block size itself parameterized, although I do agree that using a full
FS 
block is a bit excessive.  Also, I am not sure of any real advantage to
a 
large inode block at all; simply using the smallest one possible I would 
think to be sufficient.  If its because of summary block space, we could 
simply include the number of blocks following the segsum that are inode 
blocks ( or derive it from ninos) instead of taking summary space by 
listing each block's address before the FINFO's.


//Jesse Off