Hi,

On Wed, 2006-11-29 at 01:48 -0800, Andreas Dilger wrote:
quoted text
> On Nov 29, 2006  09:04 +0000, Christoph Hellwig wrote:
> >  - readdirplus
> > 
> > 	This one is completely unneeded as a kernel API.  Doing readdir
> > 	plus calls on the wire makes a lot of sense and we already do
> > 	that for NFSv3+.  Doing this at the syscall layer just means
> > 	kernel bloat - syscalls are very cheap.
> 
> The question is how does the filesystem know that the application is
> going to do readdir + stat every file?  It has to do this as a heuristic
> implemented in the filesystem to determine if the ->getattr() calls match
> the ->readdir() order.  If the application knows that it is going to be
> doing this (e.g. ls, GNU rm, find, etc) then why not let the filesystem
> take advantage of this information?  If combined with the statlite
> interface, it can make a huge difference for clustered filesystems.
> 
> Cheers, Andreas

I agree that this is a good plan, but I'd been looking at this idea from
a different direction recently. The in kernel NFS server calls
vfs_getattr from its filldir routine for readdirplus and this means not
only are we unable to optimise performance by (for example) sorting
groups of getattr calls so that we read the inodes in disk block order,
but also that its effectively enforcing a locking order of the inodes on
us too. Since we can have async locking in GFS2, we should be able to do
"lockahead" with readdirplus too.

I had been considering proposing a readdirplus export operation, but
since this thread has come up, perhaps a file operation would be
preferable as it could solve two problems with one operation?

Steve.


-
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