On Tue, Jul 23, 2002 at 11:25:58AM -0400, Thor Lancelot Simon wrote:
> On Tue, Jul 23, 2002 at 12:03:57AM -0700, Chuck Silvers wrote:
> > 
> > the BSD 4.4 buffer cache is the only one I know of that has a fixed size
> > for all buffers, that's why this isn't so much of a problem in other
> > systems.
> 
> The rest of your message seems to make sense, but I don't really buy this
> part.  Even if the buffers have variable virtual size, they can't use less
> virtual than physical space -- and to cache a 32K filesystem block, you
> need 32K of space, right?

Not really.  you only need enough space for a fragment - particularly
true for directory entries since they are probably small.

Also (I guess) the buffer cache is used for inodes - which are 128
bytes.

Maybe some sort of kernel mmap() could be used for directory fragments
- after all you can (probably) trust the kernel not to write to the
rest of the page (or even fs block).  Careful allocation of fragments
might mean that some blocks would tend to contain only directories
(which may, or may not, help).

Do directories need to be written back on delete?  I would have
thought it unnecessary, provided the freed blocks aren't put into
the freelist until after the inode has been written back it
shouldn't matter which order the writes are done in.  fsck should
fix it all up.....
Even the inode write only need to be 'sometime soon' and 'a good
thing to do' if running out of space'.
I must go for a grovel through all this code...
I presume that 'softdeps' is trying to do something like this.

	David

-- 
David Laight: david@l8s.co.uk