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 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.