All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Barton <eeb@sun.com>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] Reducing amount of glimpses
Date: Sat, 02 Feb 2008 06:39:14 +0000	[thread overview]
Message-ID: <00dc01c86566$54235390$0281a8c0@ebpc> (raw)
In-Reply-To: <A1C83110-58BF-43A2-88F3-68C6C53BFB6C@sun.com>

Oleg,

Reduction (as you describe) is an absolutely essential strategy
to achieve scalability.  So without having checked through all the
details of your idea, it feels like absolutely the right solution.

If your idea not only changes latencies but also significant orderings,
I'll feel less secure.  Have you thought it all through?

    Cheers,
              Eric

> -----Original Message-----
> From: lustre-devel-bounces at lists.lustre.org 
> [mailto:lustre-devel-bounces at lists.lustre.org] On Behalf Of 
> Oleg Drokin
> Sent: 02 February 2008 6:27 AM
> To: lustre-devel at clusterfs.com
> Subject: [Lustre-devel] Reducing amount of glimpses
> 
> Hello!
> 
>     Doing some large scale testing at ORNL, interesting 
> pattern came up.
>     Suppose we are doing large-scale IOR testing on a shared file.
>     Some unlucky client does its writing at highest offset 
> (or, at the  
> beginning,
>     was unlucky enough to grab whole-object PW lock).
>     As other clients do their writes, they would do glimpses 
> first to  
> find out file
>     size. Now those glimpses turn into thousands of glimpse requests  
> to that poor
>     client. And many of them actually coming in parallel.
>     So I was thinking - perhaps it would be nice for a  
> filter_intent_policy() to check
>     if there are any glimpse requests being in flight to that client  
> already for that
>     same lock, and if there are, just wait for the request to return  
> and use data from
>     there?
>     Of course potential caveat here is that we have no way to 
> tell if  
> the request reached
>     client by the time we started our processing or not, and so  
> potentially we might get
>     size data that is a bit stale, but I wonder if this is critical  
> enough in our case?
> 
>     Any ideas?
> 
> Bye,
>      Oleg
> _______________________________________________
> Lustre-devel mailing list
> Lustre-devel at lists.lustre.org
> http://lists.lustre.org/mailman/listinfo/lustre-devel
> 

  reply	other threads:[~2008-02-02  6:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-02  6:26 [Lustre-devel] Reducing amount of glimpses Oleg Drokin
2008-02-02  6:39 ` Eric Barton [this message]
2008-02-02  7:00   ` Oleg Drokin
2008-02-02  7:40     ` Andreas Dilger
2008-02-02 11:22 ` Nikita Danilov

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='00dc01c86566$54235390$0281a8c0@ebpc' \
    --to=eeb@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.