Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Tue, 7 Mar 2000 13:05:10 +0000 (GMT) | Subject | Re: Does your change make find faster by changing where it is storedor where it is returned? |
| |
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/
| |