From: Peter Braam <Peter.Braam@Sun.COM>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] MDWBC and how much to trust clients
Date: Thu, 09 Oct 2008 08:04:08 -0600 [thread overview]
Message-ID: <C5136B78.6085%peter.braam@sun.com> (raw)
In-Reply-To: <18667.10276.857149.242018@gargle.gargle.HOWL>
You'll need to limit this to the requests that have dependencies. With the
algorithm below every server starts looking at every request - that probably
kills the scaling you want to achieve.
Peter
On 10/7/08 3:13 AM, "Nikita Danilov" <Nikita.Danilov@Sun.COM> wrote:
> Nikita Danilov writes:
>> Eric Barton writes:
>>> Nikita,
>>
>> Hello,
>
> [...]
>
>>
>> as Peter mentioned, we discussed this topic during the Moscow
>> meeting. If I am not mistaken, we converged to the idea that before
>> committing an epoch, every mdt composes some kind of a `summary',
>> containing enough information for verification of a global consistency,
>> and this summary is passed though every server as a ticket, with every
>
> This can be simplified. Suppose total amount of `data', describing all
> updates within given epoch is D, and there are N md servers in a cmd
> cluster. Then total network traffic incurred by this algorithm is
>
> D /* updates from client to all servers */ +
> D*N /* cycle summary through all servers */
>
> that is, (N + 1)*D bytes, transferred in 2*N messages. So we won't
> increase network traffic by broadcasting _all_ epoch updates to _every_
> server (so that each server gets complete set of all updates within the
> epoch). In this latter case, servers can prove that epoch is consistent
> by
>
> - checking global consistency locally,
>
> - calculating md5 signature of all epoch updates, and
>
> - exchanging these signatures, to check that client sent the same
> set of updates to everybody.
>
> This results in
>
> D*N /* broadcast epoch updates to all servers */ +
> e*N /* exchange signatures */
>
> that is N*(D + e), for some small e, bytes transferred in 2*N
> messages. Having complete set of updates on every server would probably
> help in other places too.
>
>
>> server `approving' some bits in the summary accumulated so far, and
>
> [...]
>
>>>
>>> Thoughts?
>>>
>>> Cheers,
>>> Eric
>>
>
> Nikita.
next prev parent reply other threads:[~2008-10-09 14:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-06 2:53 [Lustre-devel] MDWBC and how much to trust clients Eric Barton
2008-10-06 3:19 ` Peter Braam
2008-10-06 15:55 ` Nikita Danilov
2008-10-07 9:13 ` Nikita Danilov
2008-10-09 14:04 ` Peter Braam [this message]
2008-10-09 16:13 ` 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=C5136B78.6085%peter.braam@sun.com \
--to=peter.braam@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.