Re: [Opendlm-devel] Orphan lock requirements for using OpenDLM with OpenGFS

--=-iq9nUTIgCyJjVEcbtupH
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

There is another big gap :

The current orphan lock mechanism is only valid for lock client failed
case. In node fail case, all locks (including orphan locks) held by this
node will be cleaned. I've poped this issue to this list in previous
mail. (please check the attachment for more detailed information)

Best Regards,
Stan

On Thu, 2004-04-08 at 03:15, Cahill, Ben M wrote:
> Hi all,
> 
> Yesterday, I updated OpenGFS' DESIGN-opendlm doc to attempt to describe
> requirements (as I understand them at the moment) for the use of OpenDLM
> orphan locks in support of OpenGFS journal recovery.  I'd be grateful
> for comments and suggestions.
> 
> The two biggest gaps seem to be:
> 
> 1)  The ability to grab a lock that's being "held" as an orphan.
> OpenGFS needs to be able to grab just a few special locks (e.g. journal
> lock) on resources that may be locked as orphans held by a dead node.
> We need to ignore the orphans, *but not* ignore other locks that may be
> non-orphans.  There seems to be no API way of doing that (looking at the
> programmers guide) ... Do we need a new "LKM_IGNOREORPHANS" flag or
> similar?
> 
> 2)  After journal recovery, we need to purge all those orphans ...  But,
> only those for the filesystem that was just recovered (there can be
> multiple OGFS filesystems mounted in the cluster).  All kernel-space
> OpenDLM clients use the same "pid" of 0xF7F7F7F7.  A call to purge would
> blow away *all* locks belonging to (kernel space clients on) the dead
> node, not just the ones for the recovered filesystem ...
> 
> 2) (cont'd)  ... To differentiate filesystems/lockspaces, we've created
> a 32-bit hash of a unique string.  The hash value becomes part of the
> lockname.  Could we use this 32-bit hash somehow as a cluster-wide
> client identifier, so purge would clean out only this client's locks?
> 
> 
> One other question ... For user-space clients, how does a pid identify a
> given client *beyond the scope of a single node*, i.e. across the
> cluster?  Can a client on one node ask to purge locks from a client on
> another node?  How does it know which pid to purge?
> 
> -- Ben --
> 
> Opinions (and questions) are mine, not Intel's
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id70&alloc_id638&opk
> _______________________________________________
> Opendlm-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/opendlm-devel
-- 
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}

--=-iq9nUTIgCyJjVEcbtupH
Content-Disposition: inline
Content-Type: message/rfc822

Return-Path: <[email protected]>
Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by
	linux.co.intel.com (8.11.6/8.11.6) with ESMTP id hAQH6N608668 for
	<[email protected]>; Wed, 26 Nov 2003 09:06:23 -0800
Received: from caduceus.jf.intel.com (caduceus.jf.intel.com [10.7.208.8])
	by talaria.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35
	2003/05/22 21:18:01 rfjohns1 Exp $) with ESMTP id hAQGuDw20037 for
	<[email protected]>; Wed, 26 Nov 2003 16:56:13 GMT
Received: from sc8-sf-list1.sourceforge.net (lists.sourceforge.net
	[66.35.250.206]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.11.6/d:
	major-outer.mc,v 1.9 2003/11/03 20:24:21 root Exp $) with ESMTP id
	hAQH6aQ7018020 for <[email protected]>; Wed, 26 Nov 2003
	17:06:37 GMT
Received: from sc8-sf-list2-b.sourceforge.net ([10.3.1.14]
	helo=sc8-sf-list2.sourceforge.net) by sc8-sf-list1.sourceforge.net with
	esmtp  (Cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.31-VA-mm2 #1 (Debian)) id
	1AP37B-0003Lm-00 for <[email protected]>; Wed, 26 Nov 2003
	09:06:09 -0800
Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13]
	helo=sc8-sf-list1.sourceforge.net) by sc8-sf-list2.sourceforge.net with
	esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 1AP37l-0003xe-00; Wed, 26 Nov 2003
	09:06:45 -0800
Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.12]
	helo=sc8-sf-mx2.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp
	(Cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.31-VA-mm2 #1 (Debian)) id
	1AP36n-0003HM-00 for <[email protected]>; Wed, 26 Nov
	2003 09:05:45 -0800
Received: from [218.22.21.7] (helo=ustc.edu) by sc8-sf-mx2.sourceforge.net
	with esmtp (Exim 4.24) id 1AP36n-0007pw-5y for
	[email protected]; Wed, 26 Nov 2003 09:05:45 -0800
Received: (qmail 28792 invoked by uid 0); 26 Nov 2003 17:05:43 -0000
Received: from unknown (HELO stanw) (stanley.wang@[61.173.21.79])
	(envelope-sender <[email protected]>) by 0 (magicmail-2.1)
	with SMTP for <[email protected]>; 26 Nov 2003 17:05:43
	-0000
Subject: Re: [Opendlm-devel] Question about orphan lock behavior
From: Stanley Wang <[email protected]>
To: OpenDLM-DEV <[email protected]>
Cc: Ben M Cahill <[email protected]>
In-Reply-To: <1069630969.3467.9.camel@stanw>
References: <[email protected]>
	 <1069630969.3467.9.camel@stanw>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-+OzWo1jaosALDekL706e"
Message-Id: <1069895129.3745.67.camel@stanw>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
X-Spam-Report: Spam Filtering performed by sourceforge.net. See
	http://spamassassin.org/tag/ for more details. Report problems to
	https://sf.net/tracker/?func=add&group_id=1&atid=200001 1.9
	DATE_IN_FUTURE_06_12   Date: is 6 to 12 hours after Received: date
Sender: [email protected]
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [email protected]
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: 
	<https://lists.sourceforge.net/lists/listinfo/opendlm-devel>,
	<mailto:[email protected]?subject=subscribe>
List-Id: <opendlm-devel.lists.sourceforge.net>
List-Unsubscribe: 
	<https://lists.sourceforge.net/lists/listinfo/opendlm-devel>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: 
	<http://sourceforge.net/mailarchive/forum.php?forum=opendlm-devel>
Date: Thu, 27 Nov 2003 01:05:29 +0000
X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang)
X-Evolution-Source: imap://[email protected]/


--=-+OzWo1jaosALDekL706e
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sun, 2003-11-23 at 23:42, Stanley Wang wrote:
> > 2. When a purge requset is received by the lock master, the following
> > call trace would be traveled:
> > pti_read_request->master_purge->there some interaction between the
> > purger and the lock master, and the lock master will do the purge stuff
> > when it receives "PREQ_DOIT"->purgelocks->purgelist
> >=20
> > The purgelist() should just purge all orphan locks that specified by th=
e
> > cid and pid, but in fact, there are more stuff than I expect. An
> > orphanable lock that is not in the wait queue will be marked as orphan
> > lock in this function!!!! Should this work be moved to clmr_clean_queue=
,
> > shouldn't? (If I make some mistakes here, please help me to point it
> > out.)
>=20
> After reading more codes, I found that I make some mistakes here. The
> work mentioned previous is not redundant. A purge request with
> "PURGE_DEAD" will be generated when a lock client(EX. a process) died.
> On the other hand, if a lock client would like to purge locks held by a
> died client, the "PURGE_FORCE" should be set.
More thinking about purge operation:
When a client want to purge locks held by the client in different node,
it simply forward a purge request to the client that should be purged,
and all purge works(send purge request to all nodes in the cluster, etc)
will be done by the client that should be purged. Hence there should be
some issues when a node fails:
Node "A" is lock master for lock resource "x", and node "B" held a
orphanable lock on lock resource "x". If node "B" failed, the orphanable
lock became orphan lock(with my last patch). Finially there is no way to
purge this orphan lock, because purge request could not be broadcasted
by node "B" any more, right?
Is there any consideration about orphan lock held by failed node when
implement OpenDLM? Anyone knows that?

Best Regards,
Stan
--=20
SW Engineer, Intel Corporation.
Intel China Software Lab.=20
Tel: 021-52574545 ext. 1171=20
iNet: 8-752-1171=20
=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}

--=-+OzWo1jaosALDekL706e
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)

iD8DBQA/xU3ZNpqLdeE5Cn8RAqhuAJ91ivT62PZzQW6zsIjZeStplnWbqQCfRKWs
VcFXZpNlXyyXHeRDCI6cE7k=
=RwnO
-----END PGP SIGNATURE-----

--=-+OzWo1jaosALDekL706e--



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Opendlm-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opendlm-devel
--=-iq9nUTIgCyJjVEcbtupH--



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click