All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.