[Lustre-devel] statahead feature

Alex Zhuravlev Alex.Zhuravlev at Sun.COM
Thu Jul 24 21:41:30 PDT 2008


Yong Fan wrote:
> Lockless getattr RPC for "ls -l" is a good idea. But whether all the 
> getattr RPC will be lockless or not?
> If not, how to distinguish them from "stat(2)" case? by intent or 
> something else?
> Statahead is based on forecast, it maybe wrong. We should guarantee the 
> proper lock(s) is held even
> if the statahead is wrong.

no, I don't think we need lock always: you just did getattr and fill inode
with fresh attributes, then you release lock, somebody changes attributes
on the server and only then userspace application gets attributes (already
non-fresh). so, what lock gives you in this case?

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

thanks, Alex



More information about the lustre-devel mailing list