Re: Does your change make find faster by changing where it is storedor where it is returned?

From: Stephen C. Tweedie (sct@redhat.com)
Date: Tue Mar 07 2000 - 08:05:10 EST


Hi,

On Tue, 07 Mar 2000 00:28:51 +0300, Hans Reiser <reiser@idiom.com>
said:

> Ok, you may have been wondering where my questions were going, now I
> can explain.

> You are proposing changing the VFS interface for an ext2 specific
> optimization.

But it's not! The proposed dentry change is already in widespread use
in other Unixen. The user-visible structure field (d_type in struct
dirent) is already present in glibc. The proposal, then, is to use a
field which already exists but which is currently always set to a null
value because the kernel API doesn't pass it back. ext2 is currently
the only Linux filesystem which supports that field, but it's definitely
not an ext2-specific innovation.

> 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.

Possibly, but the stat() way of doing things has its own problems: it
required an inode lookup internally, which basically requires an
unconditional iget, and it only returns one item at a time. Directory
scanning is a lightweight operation which doesn't need to pull in
metadata, except when you want to scan an entire tree. In that case,
the only thing you care about is whether a dirent is a subdirectory or
not, which is why the dentry type is valuable at that point.

--Stephen

-
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