Subject: Re: Overlapping bread(9) behaviour
To: None <tls@rek.tjls.com>
From: Stephen M. Rumble <stephen.rumble@utoronto.ca>
List: tech-kern
Date: 07/03/2007 13:48:15
Quoting Thor Lancelot Simon <tls@rek.tjls.com>:

> I agree.  The manual should also note that the "buffer cache" is now
> really merely the "metadata cache".  I try to use that terminology but
> it's a chore to be consistent about it.

I'll update the docs and adopt this terminology.

> I agree.  Though if EFS uses variable-size extents for directories, you're
> going to have to split them into fixed-size buffers or, possibly, bite the
> bullet and arrange to keep directories in the page cache (this has been
> hacked on a few times but nobody's got an implementation that works).  One
> thing that may help is that we now have a "nested buffer" abstraction due
> to Reinoud's UDF work, which may make it much, much easier to scatter and
> gather variable size I/Os to/from fixed-size buffers without the kind of
> evil we used before -- I think there's a nestiobuf(9) manual page.

Although EFS currently violates the way the buffer cache is intended  
to work, it doesn't lose. Thanks to read-only mode, accesses aren't  
overlapping, and things work as expected. I'll change it to conform,  
however.

EFS does use variable-sized extents for files, directories, and  
symlinks, but it has a strong notion of a 512-byte 'basic block'. Each  
directory block is one basic block in size, so it seems easy to fit  
into the present buffer cache design, but may be a bit inefficient  
(one buffer per directory block seems a little wasteful).

Thanks for the nestiobuf hint. I'll have to check that out.

> As I recall, SGI's EFS had 32-bit (maybe signed 32-bit?) size limitations,
> which were "addressed" by replacing it with XFS.  I'm curious -- were you
> planning to extend EFS for larger disks?  In a lot of ways it would be a
> nice clean replacement for FFS.

I have considered extending EFS to be read/write and SGI-compatible  
solely as a learning exercise. After that, making it work with larger  
disks would be a trivial, if incompatible (and perhaps sub-optimally  
performing, I don't know how it'd scale) extension. The current size  
limitations are due to several factors, including lots of signed  
integers and shorts. The main limitation, however, is the 24-bit  
extent pointer, which limits the filesystem size to 8GB.

I think, however, time would be better spent on the ZFS SoC. EFS is  
just a very outdated filesystem design.

Steve