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: Wed, 24 Dec 2008 13:32:51 +0300	[thread overview]
Message-ID: <49520FD3.6040007@sun.com> (raw)
In-Reply-To: <18768.56976.692985.84810@gargle.gargle.HOWL>

Hello,

Nikita Danilov wrote:
> So let's suppose we have four servers and three operations:
> 
>      S0   S1   S2   S3
> OP0  U1   U2
> OP1       U3   U4
> OP2            U5   U6
> 
> Where `U?' means that a given operation sent an update to a given
> server, and all updates happen to be conflicting.
> 
> Suppose that transaction groups with these updates commit at the same
> time and servers are ready to send information to each other. What
> information each server sends and where?

instead of digging right into details, let's agree about few simple statements
the idea is based on ?


(0) operation is globally committed if no operation it depends on can be aborted

(1) some external mechanism order operations and updates (e.g. LDLM, local locking, etc)

(2) if update U1 executed before update U2 and U2 is committed, then U1 must be committed

(3) requirement: if operation O2 depends on operation O1, then O1 has conflicting
     update on same server with O2

     example 1: mkdir /a; touch /a/b
      mkdir consists of two updates: U1 - create object on mds1, U2 - creates dir
      entry on mds2. touch consists of single update: U3 - to create object on mds1
      and directory entry in a on mds1. U1 and U3 will be conflicting as they touch
      same object

(4) operation is globally committed if all updates this operation consists of are
     committed and everything it depends on is committed as well

     explanation: say, operation O consists of two updates U1 (server S1) and U2
     (server S2). let's say U1 depends on Ua on server S1 and U2 depends on Ub on
     server S2. we stated that any update O can depend on are already executed due
     to (1). thus Ua is already executed and Ub is already executed as well. due to
     (2) commit of U1 means commit of Ua and commit of U2 means commit of Ub.

     thus direct dependency is resolved.

     if there is any indirect dependency, it's resolved same way due to (4)


In the example above, commit of U5 means commit of U4, same for U3 and U2. IOW,
when U3 and U4 are committed, then we can consider OP1 is globally committed
(won't be aborted).

any objections?


thanks, Alex

  parent reply	other threads:[~2008-12-24 10:32 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
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 [this message]
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=49520FD3.6040007@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.