On Thu, 30 Nov 2006, Christoph Hellwig wrote:
quoted text
> On Wed, Nov 29, 2006 at 12:26:22AM -0800, Brad Boyer wrote:
>> 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.
>
> In this case you can infact already instanciate inodes froms readdir.
> Take a look at the NFS code.

Sure.  And having readdirplus over the wire is a great performance win for 
NFS, but it works only because NFS metadata consistency is already weak.

Giving applications an atomic readdirplus makes things considerably 
simpler for distributed filesystems that want to provide strong 
consistency (and a reasonable interpretation of what POSIX semantics mean 
for a distributed filesystem).  In particular, it allows the application 
(e.g. ls --color or -al) to communicate to the kernel and filesystem that 
it doesn't care about the relative ordering of each subsequent stat() with 
respect to other writers (possibly on different hosts, with whom 
synchronization can incur a heavy performance penalty), but rather only 
wants a snapshot of dentry+inode state.

As Andreas already mentioned, detecting this (exceedingly common) case may 
be possible with heuristics (e.g. watching the ordering of stat() calls vs 
the filldir resuls), but that's hardly ideal when a cleaner interface can 
explicitly capture the application's requirements.

sage
-
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