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

From: Hans Reiser (reiser@idiom.com)
Date: Tue Mar 07 2000 - 05:25:21 EST


"Stephen C. Tweedie" wrote:
>
> 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

I didn't say, do the meta-stat-data access with an iget, I meant let the FS
decide how to do it. If it does it with iget, fine, but what I want to see is a
general interface which can access arbitrary non-filebody data (which the FS can
store where it chooses and fetch how it chooses). This way we can handle ACLs
and other things as yet undreamt of in a symmetrical manner. We'll produce some
code to do this sometime in the next year I think, and then put it out for
comment and review.

You and James provided good answers to the issues I was concerned about, I guess
I just lack enthusiasm for more changes to VFS interfaces while we are trying to
port to the changes already made, and I am wrong in this. 

Best,

Hans

-- 
You can get ReiserFS at http://devlinux.org/namesys, and customizations and
industrial grade support at reiser@idiom.com.

- 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:23 EST