Distributed Replicated Block Device (DRBD) development
 help / color / mirror / Atom feed
From: Cristian Zamfir <zamf@dcs.gla.ac.uk>
To: drbd-dev@lists.linbit.com
Subject: Re: [Drbd-dev] lock for reading device state
Date: Thu, 07 Dec 2006 13:52:15 +0000	[thread overview]
Message-ID: <45781C8F.1080400@dcs.gla.ac.uk> (raw)
In-Reply-To: <20061207130920.GD7521@soda.linbit>



Lars Ellenberg wrote:
> / 2006-12-06 17:22:43 +0000
> \ Cristian Zamfir:
>>
>> Hi,
>>
>> I am using drbd to implement xen block device migration.  Right now I
>> am parsing /proc/drbd to find out if the drives are synchronized and I
>> can migrate them.
> 
> you talk about drbd state "Connected, Consistent",
> or what exactly are you parsing?

Yes, indeed, I am parsing these values: "cs:Connected 
st:Secondary/Primary ld:Consistent"


> 
>> Is there a way to obtain a lock while reading and processing this
>> information and prevent other writes to the primary device?
> 
> no. why?
> 

I wrote a script that parses /proc/drbd on the primary node. While I am 
running this script, writes to the primary device are still allowed. If 
I find that the ld state is "Consistent" then I will make this node 
secondary and the peer will become primary.
The problem is when writes happen while my script is making the peer 
node primary.

A race situation would be the following:
At moment X, I read /proc/drbd and see the ld state is consistent.
At moment X+1 a write arrives at /dev/drbd1 and the devices are not 
consistent any more. They start syncing but this may last longer, for 
instance until moment X+5.
Now, at moment X+2, I wrongly believe that the state is still 
consistentand I decide to make the peer node primary and thus loose the 
write at moment X+1.

Are my assumptions correct so far?


I'm thinking that there are two solutions: One would be to prevent any 
writes from Xen's domUs by modifying Xen.
The other would be to be able to hold a lock that prevents writes from 
reaching /dev/drbdX and release it after the processing within the 
script finishes (that is while I switch the peer device from secondary 
to primary).

I haven't looked at drbd's source yet ( I am using 0.7.22 now) but I am 
considering implementing this lock within drbd if there is no other 
solution available.

As a future project, I am also interested if there is anyone working on 
implementing multiple secondary devices. I am interested in having 
multiple replicas of the primary node.

I hope this explains more my question.
Thank you very much for your help.

Cristian


>> I need to be able to prevent writes while reading the state of
>> the device from a script external to drbd.
> 
> does not make sense to me yet?
> 
>> In case there is no existing solution, can you please give me a few
>> tips on how to start developing such a locking mechanism?
> 
> please give more details about your assumptions and reasoning,
> maybe its just that you have wrong expectations?
> 
> could also be that I'm just mentally block right now...
> 
> 	:)
> 


  reply	other threads:[~2006-12-07 13:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-06 17:22 [Drbd-dev] lock for reading device state Cristian Zamfir
2006-12-07 13:09 ` Lars Ellenberg
2006-12-07 13:52   ` Cristian Zamfir [this message]
2006-12-07 15:56     ` Lars Ellenberg
2006-12-07 20:25       ` Cristian Zamfir

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=45781C8F.1080400@dcs.gla.ac.uk \
    --to=zamf@dcs.gla.ac.uk \
    --cc=drbd-dev@lists.linbit.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox