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...
>
> :)
>
next prev parent 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