On Wed, Nov 29, 2006 at 10:18:42AM +0000, Anton Altaparmakov wrote:
quoted text
> To take NTFS as an example I know something about, the directory entry
> caches the a/c/m time as well as the data file size (needed for "ls")
> and the allocated on disk file size (needed for "du") as well as the
> inode number corresponding to the name, the flags of the inode
> (read-only, hidden, system, whether it is a file or directory, etc) and
> some other tidbits so readdirplus on NTFS can simply return wanted
> information without ever having to do a lookup() on the file name to
> obtain the inode to then use that in the stat() system call...  The
> potential decrease in work needed is tremendous in this case...
> 
> Imagine "ls -li" running with a single readdirplus() syscall and that is
> all that happens on the kernel side, too.  Not a single file name needs
> to be looked up and not a single inode needs to be loaded.  I don't
> think anyone can deny that that would be a massive speedup of "ls -li"
> for file systems whose directory entries store extra information to
> traditional unix file systems...

For a more extreme case, hfs and hfsplus don't even have a separation
between directory entries and inode information. The code creates this
separation synthetically to match the expectations of the kernel. During
a readdir(), the full catalog record is loaded from disk, but all that
is used is the information passed back to the filldir callback. The only
thing that would be needed to return extra information would be code to
copy information from the internal structure to whatever the system call
used to return data to the program.

	Brad Boyer
	flar@allandria.com

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html