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