Do the DISK objects contain a reference to a DISK-PAIR?  What about the

Can DISK's be in more than one DISK-PAIR?

I will assume some answers to these so I can give a design.

Suppose that DISK's just contain other information, but do not refer to
DISK-PAIR's and and can only exist in a single pair.

If so, then the state really should be in the DISK-PAIR and the update
should proceed this way:

      create DISK-PAIR referring to the two disks and with state = ONLINE

No update to the DISK is necessary.

If, on the contrary, the DISK's should have a reference to the DISK-PAIR to
ensure that they are never in more than one DISK-PAIR, the update would
proceed this way:

      create DISK-PAIR referring to the two disks with state = OFFLINE
      read the first disk state.
      If it has been assigned to a PAIR, abort, otherwise set it to refer to
the new DISK-PAIR.  If the update fails, delete the DISK-PAIR and abort.
      read the second disk.
      if it has been assigned to a PAIR, unassign the first disk and abort
otherwise set it to refer to the new DISK-PAIR.  If the update fails,
unwind the update to the first disk, delete the DISK-PAIR and abort
      update the DISK-PAIR to have state = ONLINE

If desired, you can update each disk at this point to have state = ONLINE.
This is really just to speed up checking if a disk is on-line.  The logic
would be:

      if a disk is not a member of a pair, it is off-line
      else if a disk has state = ONLINE, it is on-line
      else if the pair for the disk has state = ONLINE, the disk is on-line
(this check will only happen very rarely for very newly paired disks)

This update sequence is guaranteed to succeed or fail completely.  Moreover,
a disk can only be in a single pair and the online status of a disk can be
determined by checking the disk to see if it is in a pair and if that pair
has state ONLINE.

Can you move the ONLINE state to the DISK-PAIR?

On Mon, Mar 29, 2010 at 7:24 PM, zd.wbh <> wrote:

> Thanks for your quick reply, Ted.
> we are implementing a distributed system, using zookeeper for master
> metedata persistence. There's DISK object and DISK-PAIR object. when
> creating a DISK-PAIR, we need to first create a znode indicating DISK-PAIR
> object and updating the corresponding two DISK's state from DISK_OFFLINE to
> DISK_ONLINE, these operations need to be done as a whole.
> 2010-03-30
> Will
> 发件人: Ted Dunning <>
> 发送时间: 2010-03-30 10:11
> 主 题: Re: How to ensure trasaction create-and-update
> 收件人:
> This is not a good thing.  ZK gains lots of its power and reliability by
> not
> trying to do atomic updates to multiple znodes at once.
> Can you say more about the update that you want to do?  It is common for
> updates like to be such that you can order the updates and do without a
> truly atomic transaction.  For instance if one file is a list of other
> files
> (say for a queue) and you need to create a file and add a reference in the
> list of files, you can generally be safe creating the new file first and
> then doing an atomic update on the list of files secondly.  If your process
> fails between the two operations, then you may generate a small number of
> garbage files (this number can be substantially decreased by careful use of
> try/finally) which might require a cleanup process to run occasionally to
> find unreferenced and old files.
> On Mon, Mar 29, 2010 at 6:54 PM, zd.wbh <> wrote:
> >   we'd like to store some metadata in zookeeper in our upcoming project,
> > here is a special but common case: we need to create a new znode, in the
> > mean while, update another znode data. These manipulation(a create and a
> > update) need to be done as atom. We don't want to see a successful
> creation
> > and a failure updating. Is there a convenient way to ensure this
> operation?
> > Can you give me some tips?
> >
> >    I've looked into the src code, there is a tedious way to do. Extend
> > zookeeper instruction, struct a "createAndUpdate" interface and a txn
> > request, let DataTree to ensure the integrity. Will this do and the only
> > way?
> >

Reply via email to