On Wed, 2006-12-06 at 13:22 +0100, Ragnar Kjørstad wrote: > On Tue, Dec 05, 2006 at 09:55:16AM -0500, Trond Myklebust wrote: > > > 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. > > > > ... > > > > a) networked filesystem specific. The mask stuff etc adds no > > value whatsoever to actual "posix" filesystems. In fact it is > > telling the kernel that it can violate posix semantics. > > > I don't see what's network filesystem specific about it. Correct me if > I'm wrong, but today ls -l on a local filesystem will first do readdir > and then n stat calls. In the worst case scenario this will generate n+1 > disk seeks. I was referring to the caching mask. > Local filesystems go through a lot of trouble to try to make the disk > layout of the directory entries and the inodes optimal so that readahead > and caching reduces the number of seeks. > > With readdirplus on the other hand, the filesystem would be able to send > all the requests to the block layer and it would be free to optimize > through disk elevators and what not. As far as local filesystems are concerned, the procedure is still the same: read the directory contents, then do lookup() of the files returned to you by directory contents, then do getattr(). There is no way to magically queue up the getattr() calls before you have done the lookups, nor is there a way to magically queue up the lookups before you have read the directory contents. Trond - 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
