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