Hans Reiser wrote:
> You are proposing changing the VFS interface for an ext2 specific
> optimization.
No, it's not specific to ext2. Anything with type readily available
during a readdir benefits from less inode and dentry cache thrashing,
and for some fses, fewer disk reads. Ok, that only seems to be ext2,
ext3, ufs, qnx4, hpfs, udf, adfs, coda, cramfs, romfs, isofs, msdos,
vfat, umsdos, hpfs, and possibly some more of the network fses :-)
> What I propose is that if you are going to change the interface you change it
> more thoroughly and better.
I am proposing changing the interface to the one that Glibc already
exports, and which has precedent in BSD4.4. I.e., there are
applications which can use it.
There just seems to be a hole at the moment: Glibc exports d_type info
from readdir but always stores DT_UNKNOWN in it.
> That is, I propose that instead you make it possible to access any piece of
> stat-meta-data without having to access the other pieces of metadata. stat()
> forces you to access everything, and sometimes you don't want
> everything.
I see where you're going. And indeed, DJGPP provides a precedent. In
DJGPP you can set a global flag to say which parts of stat() you're not
interested in, because some things like the faked inode number are
expensive to compute.
I think what you're proposing would end up only benefitting reiserfs
users though.
Think about it: to benefit from limited stat info through a stat-like
call, you have to do a name lookup (dentry?) but somehow _not_ do an
iget. Who's going to cache that info? The dentry/inode system won't do
it.
Another possibility is to return limited not-quite-stat info in the
readdir, in addition to the type and fileno which are already returned.
I designed the binary format to allow for such extensions. So if you
have some specific bit of handy info in mind for reiserfs, it can be
returned via readdir().
-- Jamie
-
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/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:22 EST