lkml.org 
[lkml]   [2000]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.325 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site