[Lustre-devel] statahead feature

Alex Lyashkov Alexey.Lyashkov at Sun.COM
Fri Jul 25 02:37:56 PDT 2008

On Fri, 2008-07-25 at 08:41 +0400, Alex Zhuravlev wrote:

> > Another optimization (maybe) to be considered is that whether it is 
> > necessary to start one statahead thread
> > for each "ls -l" operation or not? As said by Nikita, maybe we can use a 
> > single thread for all the statahead.
> I'm not sure we need any statahead thread at all. what's wrong with issuing
> number of async RPCs from ll_getattr_it()? this way user's application drives
> statahead directly: each time stat(2) is called you tune statahead window and
> send few more RPCs again -- like data read-ahead does.
not need any statahead thread.
as alex say:
if we have UPDATE lock to parent - we can create valid dentry without
lookup and add new locked inode to him.
this looks easy to implement - call ll_readdir with i_mutex held and
pass custom fill callback.
in callback we allocate new dentry + empty locked inode (or attach new
dentry to inode if we have only update lock /ll_find_alias/ ?? ), also
submit async getattr rpc into ptlrpcd if need.
rpc completion callback set md_lock to inode and unlock inode.
also ll_getattr_it should call wait_on_inode for be sure statahead is

Alex Lyashkov <Alexey.lyashkov at sun.com>
Lustre Group, Sun Microsystems

More information about the lustre-devel mailing list