[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