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] global epochs [an alternative proposal, long and dry].
Date: Tue, 23 Dec 2008 14:31:36 +0300	[thread overview]
Message-ID: <4950CC18.1090005@sun.com> (raw)
In-Reply-To: <18768.50762.865900.238376@gargle.gargle.HOWL>

Nikita Danilov wrote:
> We are talking about few megabytes of data in network or in memory. It's
> easy to replicate this state.

I disagree - whole state can be distributed over 100K and more nodes and
some operations many need all nodes to communicate their state. this is
especially problem with lossy network.

> Again, global epochs do not depend on DLM to propagate epochs. E.g.,
> lockless IO can be implemented without any additional rpcs.

sorry, I said nothing about DLM. I said "additional RPC", which is required
in some cases. ping, for example, can issue RPC once per 60s. more over,
ping also can use tree or some different topology making epoch refresh more
complex.

> Tree reduction is but an optimization. I am pretty convinced that core
> algorithm works, because this can be proved.

sorry, works doesn't always mean "meet requirements". in our case scalability
is the top one. in this regard I don't see how this model can work well with
synchronous operations. at same time it was stated that we have to support
such operations well, e.g. for nfs exports. I also tried to point out onto
few overheads in the algorithm.

>>   * once some distributed transaction is committed on all involved servers, we can prune
>>     it and all its local successors
> 
> Either I am misunderstanding this, or this is not correct, because not
> only a given operation, but also all operations it depends on have to be
> committed, and it is not clear how this is determined.

the algorithm works starting from oldest operations and discards them when there is no
undo before this one.

> One reason I wrote so lengthy a text was that I want to spell out
> everything explicitly and unambiguously (and obviously failed in the
> latter, as ensued discussion has shown).

yes, it's well written and proven thing. the point is different - if it's clear that
in some cases it doesn't work well (see sync requirement), what the proof does?

thanks, Alex

  reply	other threads:[~2008-12-23 11:31 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-22  7:53 [Lustre-devel] global epochs [an alternative proposal, long and dry] Nikita Danilov
2008-12-22 11:52 ` Alex Zhuravlev
2008-12-22 12:45   ` Nikita Danilov
2008-12-22 13:48     ` Alexander Zarochentsev
2008-12-22 14:21       ` Nikita Danilov
2008-12-22 14:45         ` Alex Zhuravlev
2008-12-22 14:44     ` Alex Zhuravlev
2008-12-22 17:15       ` Nikita Danilov
2008-12-22 17:36         ` Alex Zhuravlev
2008-12-22 18:57           ` Nikita Danilov
2008-12-23  6:44             ` Alex Zhuravlev
2008-12-23 10:00               ` Nikita Danilov
2008-12-23 10:21                 ` Alex Zhuravlev
2008-12-23 11:06                   ` Nikita Danilov
2008-12-23 11:31                     ` Alex Zhuravlev [this message]
2008-12-23 12:50                       ` Nikita Danilov
2008-12-23 13:11                         ` Alex Zhuravlev
2008-12-23 13:24                           ` Nikita Danilov
2008-12-24 10:32                         ` Alex Zhuravlev
2008-12-24 11:37                           ` Nikita Danilov
2008-12-26  9:01                             ` Alex Zhuravlev
2008-12-23 23:37             ` Andreas Dilger
2008-12-24 12:35               ` Eric Barton
2008-12-24 16:16               ` Nikita Danilov
2009-01-15 23:40 ` [Lustre-devel] global epochs vs fsync 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=4950CC18.1090005@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.