Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Sat, Mar 09, 2013 at 08:55:42PM +0530, Satyajit Paul wrote: > 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 ? >> >> The lock is there to avoid races between looking/changing state. Again: Lock is there to avoid a state change between looking at the state, deciding if or not the open shall be successful, and incrementing the count. Not to serialize open, as that is already serialized in upper layers somewhere. >> >> 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. __ please don't Cc me, but send to list -- I'm subscribed