RE: [Opendlm-devel] Re: [ogfs-dev]False notification for recovery

Thanks, Stan,

This looks like good stuff.

Unfortunately, I did not get to it until late in the day, and need to =
stop for now, but perhaps you can fix the following problem:

	dlm_scnop() is not compiled into any of the kernel modules

2 options:

1).  Get it to build into one of the kernel modules.

2).  Use same techniques to set/read the LVB that you do elsewhere in =
the ODLM/OGFS lock module.  If it's not too much trouble, I like this =
approach better, but that's just one man's opinion.

-- Ben --

Opinions are mine, not Intel's

> -----Original Message-----
> From: [email protected]=20
> [mailto:[email protected]] On Behalf=20
> Of Stanley Wang
> Sent: Tuesday, March 02, 2004 11:10 AM
> To: [email protected]
> Cc: [email protected]
> Subject: [Opendlm-devel] Re: [ogfs-dev]False notification for recovery
>=20
> First of all, thanks for Ben's help to debug the deadman lock module.
>=20
> I've checked the bug fixes into the CVS.(Since I've no=20
> machines to test it, I=20
> don't run it really. But Ben will help me to test it. And I=20
> will try to build=20
> my own test environment ASAP.)
>=20
> Some explaination about my fixes:
>=20
> 1. Seperate "mount lock" and deadman lock.
> Every node should grab the "mount lock" first, and then try=20
> to initialize the=20
> deadman lock. After initialized deadman lock, the node knew=20
> if it is the first=20
> node to mount the OGFS. If it is not the first one, it=20
> release "mount lock"=20
> before return. If it is, "mount lock" would be released in=20
> other_may_mount which is invoked by the client(OGFS).
>=20
> 2. Using SCN to avoid false notification of recovery.
>=20
> I define three states for each deadman lock:
>=20
> 	DEADMAN_FIRST	- last holder of this lock is the first=20
> node that mount=20
> 			OGFS. The first node sets SCN to this=20
> value after it=20
> 			gets others' deadman lock=20
> 	DEADMAN_MOUNT	- last holder of this lock is the right=20
> owner. A node=20
> 			sets SCN to this value after it grabs=20
> its own deadman=20
> 			lock.
> 	DEADMAN_UMOUNT	- OGFS is un-mounted gracefully before=20
> this lock is=20
> 			released. A node sets SCN the this=20
> value when it=20
> 			un-mounts the OGFS.
>=20
> more desciption: As you know, each node queues a CR mode lock=20
> on each of other=20
> node, and if anyone other node dies, the CR lock will be=20
> granted and the node=20
> gets notified by lock AST. In AST, the SCN of this lock is=20
> checked. If the SCN=20
> is DEADMAN_UMOUNT, it means that a node un-mounted OGFS, and=20
> recoverying is not=20
> needed. If the SCN is DEADMAN_MOUNT, it means a node die=20
> before it un-mount the=20
> OGFS, recoverying is needed. And DEADMAN_FIRST only will be=20
> seen in the=20
> initializing process, it means that the right owner of the=20
> this lock requested=20
> this lock, recoverying work is not needed.
>=20
> 3. Avoid useless granting deadman lock=20
>=20
> After the first node grabs EX lock on all deadman locks, if a=20
> sequent node tries=20
> to queue CR lock on other's(execpt the first node) deadman=20
> lock, a BAST is=20
> triggered on the first node. In the original implementation,=20
> the CR lock will be=20
> granted. This behavior increasess overhead of deadman lock.=20
> And now, the=20
> requested lock state is also checked in the BAST, if it is=20
> not EX mode, this=20
> request is ignored.
>=20
> More detailed information, please read the codes.
>=20
> Any comments?
>=20
> Best Regards,
> Stan
>=20
> On Mon, 1 Mar 2004, Cahill, Ben M wrote:
>=20
> > Stan and I were chatting about the excess recovery=20
> notifications that we
> > get from the current ODLM lock module.  These happen with=20
> the current
> > deadman lock design when a client (filesystem) mounts or unmounts on
> > another node.
> >=20
> > Without going into detail ... I'm wondering if we can use the *lock
> > value blocks* of the deadman locks to communicate whether:
> >=20
> > 1)  A client has cleanly unmounted (no recovery needed)
> >=20
> > 2)  A new client has mounted (no recovery needed after=20
> first-to-mount)
> >=20
> > 3)  A node died (recovery needed)
> >=20
> > -- Ben --
> >=20
> > Opinions are mine, not Intel's
> >=20
> >=20
> > -------------------------------------------------------
> > SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> > Build and deploy apps & Web services for Linux with
> > a free DVD software kit from IBM. Click Now!
> > http://ads.osdn.com/?ad_id=1356&alloc_id438&op=CCk
> > _______________________________________________
> > Opengfs-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/opengfs-devel
> >=20
>=20
> --=20
> Opinions expressed are those of the author and do not represent Intel
> Corporation
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
> _______________________________________________
> Opendlm-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/opendlm-devel
>=20


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click