Christoph Hellwig wrote:
quoted text
> On Tue, Dec 05, 2006 at 12:56:40AM -0500, Trond Myklebust wrote:
>> On Mon, 2006-12-04 at 18:59 -0600, Rob Ross wrote:
>>> Hi all,
>>>
>>> I don't think that the group intended that there be an opendirplus(); 
>>> rather readdirplus() would simply be called instead of the usual 
>>> readdir(). We should clarify that.
>>>
>>> Regarding Peter Staubach's comments about no one ever using the 
>>> readdirplus() call; well, if people weren't performing this workload in 
>>> the first place, we wouldn't *need* this sort of call! This call is 
>>> specifically targeted at improving "ls -l" performance on large 
>>> directories, and Sage has pointed out quite nicely how that might work.
>> ...and we have pointed out how nicely this ignores the realities of
>> current caching models. There is no need for a  readdirplus() system
>> call. There may be a need for a caching barrier, but AFAICS that is all.
> 
> I think Andreas mentioned that it is useful for clustered filesystems
> that can avoid additional roundtrips this way.  That alone might now
> be enough reason for API additions, though.  The again statlite and
> readdirplus really are the most sane bits of these proposals as they
> fit nicely into the existing set of APIs.  The filehandle idiocy on
> the other hand is way of into crackpipe land.

So other than this "lite" version of the readdirplus() call, and this 
idea of making the flags indicate validity rather than accuracy, are 
there other comments on the directory-related calls? I understand that 
they might or might not ever make it in, but assuming they did, what 
other changes would you like to see?

Thanks,

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