dreaddir/fxattr

["Nicholas S Castellano" <entropy@terminator.rs.itd.umich.edu>]

>I'm still not sure about this. The delay of readdir/stat is caused by the
>multiple file lookups (e.g. several directory searches if it's a full path).
>Things which don't use the new syscall wont win. Also is it intended that the
>new library would use this syscall to reduce the work in certain situations
>(e.g. automatically with readdir).
>	Since this involves messing with the kernel, why not use a cookie 
>cache which is then backwards compatible and speeds up *all* multiple 
>operations on the same file (the lib is full of these) instead of just
>optimising the readdir/xattr case.
>	I could do this with an LRU cache in Minixfs lookup/readdir but it's
>best in the kernel to speed up all filesystems and to have path as opposed to
>directory dependency.

I agree that this is the best solution.  If we implement a new system
call we will still need to retain backwards compatibility in the
library (try new readdir call, if it is not available then use
readdir/getxattr) which will only make the syscall overhead greater in
many instances and complicates programming for those using the OS
interface directly without an intervening library interface.  Adding a
write-through directory cache in the kernel solves the original
problem without introducing new ones.

Cheers,
entropy

--
entropy -- it's not just a good idea, it's the second law.
Personal mail:      entropy@gnu.ai.mit.edu
MiNT library mail:  entropy@terminator.rs.itd.umich.edu
"what do you have against octal?" -jrb