On Wed, Nov 29, 2006 at 10:18:42AM +0000, Anton Altaparmakov wrote: > 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@xxxxxxxxxxxxx - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
