From: Alex Zhuravlev <Alex.Zhuravlev@Sun.COM>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] statahead feature
Date: Fri, 25 Jul 2008 08:41:30 +0400 [thread overview]
Message-ID: <4889597A.6060109@sun.com> (raw)
In-Reply-To: <488957EC.1040701@sun.com>
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
next prev parent reply other threads:[~2008-07-25 4:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-24 10:19 [Lustre-devel] statahead feature Alex Zhuravlev
2008-07-24 11:35 ` Alex Lyashkov
2008-07-24 16:27 ` Peter Braam
2008-07-24 18:56 ` Alex Zhuravlev
2008-07-25 4:34 ` Yong Fan
2008-07-25 4:41 ` Alex Zhuravlev [this message]
2008-07-25 5:04 ` Ragnar Kjørstad
2008-07-25 5:17 ` Alex Zhuravlev
2008-07-28 22:02 ` Andreas Dilger
2008-07-25 9:37 ` Alex Lyashkov
2008-07-25 12:29 ` Alex Zhuravlev
2008-07-25 19:41 ` Andreas Dilger
2008-07-25 19:50 ` Alex Zhuravlev
2008-07-25 4:44 ` Alex Zhuravlev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4889597A.6060109@sun.com \
--to=alex.zhuravlev@sun.com \
--cc=lustre-devel@lists.lustre.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox