RE: RE: [Opendlm-devel] ODLM/OGFS Recovery
Stanley Wang <[email protected]> Wed, 05 May 2004 14:50:14 +0000
| Newsgroups | gmane.comp.file-systems.opengfs.devel |
|---|---|
| Message-ID | <1083768614.3409.2.camel@stanw> |
--=-apuTZNZ9tS/AUSBsdGtd
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Tue, 2004-05-04 at 14:35, Zickus II, Don wrote:
> > > I think this is handled during ODLM's lock recovery process, which=20
> > > invalidates LVBs that might have been altered by a dead node. See
> > > clmr_clean() and clmr_lkvlb().
> >=20
> > Yes, ODLM will invalidate LVBs that might have been altered=20
> > by a dead node. But my concern is :=20
> >=20
> > If there is only one PW or EX lock request in the wait queue=20
> > of this resource, we won't get DLM_VALNOTVALID (even the LVB=20
> > of this resouce is
> > invalid) when the queued request is granted.
> >=20
> > It means that we might miss some locks held by dead node.=20
> > Please read:=20
> > rc_barrier6->wake_all_locks->convert_locks->grant_convert->valueblock
> >=20
> > Any comments?
> >=20
>=20
> By the time it gets to valueblock, the resource has already been invalida=
ted such that the only code path it would take in valueblock() is the very =
last _else_ statement (assuming the first node with the granting lock will =
also be the master) which returns DLM_VALNOTVALID.
>=20
> Do you see it differently?
Sorry, I mis-unstanded the first "if-eles" :( You are right.
Thanks a lot !
Best Regards,
Stan
--=20
Opinions expressed are those of the author and do not represent Intel
Corporation
=20
"gpg --recv-keys --keyserver wwwkeys.pgp.net E1390A7F"
{E1390A7F:3AD1 1B0C 2019 E183 0CFF 55E8 369A 8B75 E139 0A7F}
--=-apuTZNZ9tS/AUSBsdGtd
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQBAmP8mNpqLdeE5Cn8RAhIqAJoCCV63W+YHYEDpwZC+EpPsRABtCwCfUQEv
E6TN1kuSTBOKGHEpV9MJ+Rc=
=4qyq
-----END PGP SIGNATURE-----
--=-apuTZNZ9tS/AUSBsdGtd--
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3