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

On Wed, 2004-03-03 at 05:50, Cahill, Ben M wrote:
> Thanks, Stan,
>=20
> This looks like good stuff.
>=20
> Unfortunately, I did not get to it until late in the day, and need to s=
top for now, but perhaps you can fix the following problem:
>=20
> 	dlm_scnop() is not compiled into any of the kernel modules

Thanks :)
Because I have no machine to test it yesterday (I've borrowed two now:),
I didn't find that dlm_scnop is in user space only. Sorry for my
careless. After check the OpenDLM's codes, I found it's quite easy to
bring dlm_scnop to kernel space, I don't know why it is in user space
only (any comments?). However, I would keep it intact and change to use
standard LVB operation.

Best Regards,
Stan

> 2 options:
>=20
> 1).  Get it to build into one of the kernel modules.
>=20
> 2).  Use same techniques to set/read the LVB that you do elsewhere in t=
he ODLM/OGFS lock module.  If it's not too much trouble, I like this appr=
oach better, but that's just one man's opinion.
>=20
> -- Ben --
>=20
> Opinions are mine, not Intel's
>=20
> > -----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 recover=
y
> >=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 o=
n
> > > 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=C3=8Ck
> > > _______________________________________________
> > > 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
>=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=C3=8Ck
> _______________________________________________
> Opendlm-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/opendlm-devel
--=20
Opinions expressed are those of the author and do not represent Intel
Corporation
"gpg --recv-keys --keyserver wwwkeys.pgp.net E1390A7F"
{E1390A7F:3AD1 1B0C 2019 E183 0CFF  55E8 369A 8B75 E139 0A7F}



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