[DRBD-user] State change failed: Device is held open by someone

Satyajit Paul satyajit.paul at aricent.com
Sat Mar 9 16:25:42 CET 2013

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


Hello Lars,

Thanks for the reply.

Can you please share some thoughts, in case of drbd_open() function, locking/unlocking is explicitly invoked and incase of drbd_close() function, it is not invoked explicitly ?


Thanks & Regards,
Satyajit Paul
Software Engineer
India
Mob. 8802057091
________________________________________
From: drbd-user-bounces at lists.linbit.com [drbd-user-bounces at lists.linbit.com] On Behalf Of Lars Ellenberg [lars.ellenberg at linbit.com]
Sent: Friday, March 08, 2013 7:54 PM
To: drbd-user at lists.linbit.com
Subject: Re: [DRBD-user] State change failed: Device is held open by someone

On Fri, Mar 08, 2013 at 05:07:23PM +0530, Satyajit Paul wrote:
> Hello,
>
> When I wanted to change the state of DRBD from primary to secondary, sometimes I get the "Device is held open by someone" issue.
> I looked into the code drbd_main.c (DRBD Release 8.0.11) and found that the error is set from the below code.
>
>     else if( ns.role == Secondary && mdev->open_cnt )
>         rv=SS_DeviceInUse;
>
> I put debug logs and found that sometimes "open_cnt" variable is not
> equal to zero that results in the error. "open_cnt" variable is
> incremented and decremented from the function drbd_open() and
> drbd_close() respectively. In function drbd_open(), "open_cnt"
> variable is handled within locking/unlocking function to avoid race
> condition whereas in drbd_close(), no such locking/unlocking function
> is there to handle its critical section. Can we imagine any scenario
> that due to the absence of locking/unlocking function in the
> drbd_close() function, race condition is occurring that results in the
> wrong value of "open_cnt" variable.

Very unlikely, as last time I checked,
it is serialized higher up in the stack (in i_mutex possibly?).

The lock is there to avoid races between looking/changing state.

See also:
http://www.gossamer-threads.com/lists/drbd/users/17007?do=post_view_threaded
This has come up so many times, really...

and if all else fails, and you really did not overlook some
devicemapper or other user,
I maintain it is *udev* *udev* *udev*, some short lived blkid or other
funky thing that looks at the device right when you want to demote it..

But feel free to change that to an atomic_t, if you think it helps.

--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
_______________________________________________
drbd-user mailing list
drbd-user at lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user




===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================



More information about the drbd-user mailing list