>
> On Fri, 8 Oct 1999, Alexander Viro wrote:
>
> > Stephen, Ingo, could you look at the stuff above? Methink it means that we
> > either must separate ext2_truncate() for directories (doing bforget() on
> > the data blocks) _or_ put the directory blocks into the page cache and do
> > block_flush(). I'ld rather prefer the latter. Moreover, we can stuff the
> > indirect blocks into the page cache too (using negative offsets). That
> > would leave us with pure buffer cache only for static structures.
>
> yep we knew about this problem ... it's not quite an easy hack though.
> Putting the directory block cache (and symlink block cache) into the page
> cache would be the preferred method - this would also clean up the code
> alot i think.
More or less random comments/questions:
1) Is ext2_bread() vs. bread() separation in fs/ext2/* a first step to
that? (I.e. data blocks vs. inode/bitmap/indirect ones)
2) Sometime ago there was a pretty impressive patch excluding large part
of ext2_find_entry() (it caches the offset into dentry and invalidates it
if needed) and I have a code for cyclic lookups in a directory (cheap
hack, but it really speeds the things up for ls -l and friends). Both
would go nicely into this scheme.
3) We ought to switch from (bh+pointer) to (page+pointer) in namei.c.
4) I still think that indirect blocks may go into the page cache - that
would further simplify truncate(). OTOH the method used by BSD (indirect
block covering addresses from n to n+block_size*pointers_per_block gets
an address -n, double indirect block covering the area from n to n+...
gets -n-block_size, triple indirect - -n-2*block size) will be wasteful
for situations when block size is smaller than page.
5) Who works on that? I would try to do the thing, but if there already is
some code I'ld like to look at it, indeed.
Comments?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/