Re: [ogfs-dev]False notification for recovery

First of all, thanks for Ben's help to debug the deadman lock module.

I've checked the bug fixes into the CVS.(Since I've no machines to test i=
t, I=20
don't run it really. But Ben will help me to test it. And I will try to b=
uild=20
my own test environment ASAP.)

Some explaination about my fixes:

1. Seperate "mount lock" and deadman lock.
Every node should grab the "mount lock" first, and then try to initialize=
 the=20
deadman lock. After initialized deadman lock, the node knew if it is the =
first=20
node to mount the OGFS. If it is not the first one, it release "mount loc=
k"=20
before return. If it is, "mount lock" would be released in=20
other_may_mount which is invoked by the client(OGFS).

2. Using SCN to avoid false notification of recovery.

I define three states for each deadman lock:

	DEADMAN_FIRST	- last holder of this lock is the first node that mount=20
			OGFS. The first node sets SCN to this value after it=20
			gets others' deadman lock=20
	DEADMAN_MOUNT	- last holder of this lock is the right owner. A node=20
			sets SCN to this value after it grabs its own deadman=20
			lock.
	DEADMAN_UMOUNT	- OGFS is un-mounted gracefully before this lock is=20
			released. A node sets SCN the this value when it=20
			un-mounts the OGFS.

more desciption: As you know, each node queues a CR mode lock on each of =
other=20
node, and if anyone other node dies, the CR lock will be granted and the =
node=20
gets notified by lock AST. In AST, the SCN of this lock is checked. If th=
e SCN=20
is DEADMAN_UMOUNT, it means that a node un-mounted OGFS, and recoverying =
is not=20
needed. If the SCN is DEADMAN_MOUNT, it means a node die before it un-mou=
nt the=20
OGFS, recoverying is needed. And DEADMAN_FIRST only will be seen in the=20
initializing process, it means that the right owner of the this lock requ=
ested=20
this lock, recoverying work is not needed.

3. Avoid useless granting deadman lock=20

After the first node grabs EX lock on all deadman locks, if a sequent nod=
e tries=20
to queue CR lock on other's(execpt the first node) deadman lock, a BAST i=
s=20
triggered on the first node. In the original implementation, the CR lock =
will be=20
granted. This behavior increasess overhead of deadman lock. And now, the=20
requested lock state is also checked in the BAST, if it is not EX mode, t=
his=20
request is ignored.

More detailed information, please read the codes.

Any comments?

Best Regards,
Stan

On Mon, 1 Mar 2004, Cahill, Ben M wrote:

> Stan and I were chatting about the excess recovery notifications that w=
e
> get from the current ODLM lock module.  These happen with 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 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
Opinions expressed are those of the author and do not represent Intel
Corporation




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