From: David Teigland <teigland@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] cluster4 gfs_controld
Date: Thu, 13 Oct 2011 10:20:59 -0400 [thread overview]
Message-ID: <20111013142059.GA6704@redhat.com> (raw)
Here's the outline of my plan to remove/replace the essential bits of
gfs_controld in cluster4. I expect it'll go away entirely, but there
could be one or two minor things it would still handle on the side.
kernel dlm/gfs2 will continue to be operable with either
. cluster3 dlm_controld/gfs_controld combination, or
. cluster4 dlm_controld only
Two main things from gfs_controld need replacing:
1. jid allocation, first mounter
cluster3
. both from gfs_controld
cluster4
. jid from dlm-kernel "slots" which will be assigned similarly
. first mounter using a dlm lock in lock_dlm
2. recovery coordination, failure notification
cluster3
. coordination of dlm-kernel/gfs-kernel recovery is done
indirectly in userspace between dlm_controld/gfs_controld,
which then toggle sysfs files.
. write("sysfs block", 0) -> block_store(1)
write("sysfs recover", jid) -> recover_store(jid)
write("sysfs block", 1) -> block_store(0)
cluster4
. coordination of dlm-kernel/gfs-kernel recovery is done
directly in kernel using callbacks from dlm-kernel to gfs-kernel.
. gdlm_mount(struct gfs2_sbd *sdp, const char *table, int *first, int *jid)
calls dlm_recover_register(dlm, &jid, &recover_callbacks)
. gdlm_recover_prep() -> block_store(1)
gdlm_recover_slot(jid) -> recover_store(jid)
gdlm_recover_done() -> block_store(0)
cluster3 dlm/gfs recovery
. dlm_controld sees nodedown (libcpg)
. gfs_controld sees nodedown (libcpg)
. dlm_controld stops dlm-kernel (sysfs control 0)
. gfs_controld stops gfs-kernel (sysfs block 1)
. dlm_controld waits for gfs_controld kernel stop (libdlmcontrol)
. gfs_controld waits for dlm_controld kernel stop (libdlmcontrol)
. dlm_controld syncs state among all nodes (libcpg)
. gfs_controld syncs state among all nodes (libcpg)
. dlm_controld starts dlm-kernel recovery (sysfs control 1)
. gfs_controld starts gfs-kernel recovery (sysfs recover jid)
. gfs_controld starts gfs-kernel (sysfs block 0)
cluster4 dlm/gfs recovery
. dlm_controld sees nodedown (libcpg)
. dlm_controld stops dlm-kernel (sysfs control 0)
. dlm-kernel stops gfs-kernel (callback block 1)
. dlm_controld syncs state among all nodes (libcpg)
. dlm_controld starts dlm-kernel recovery (sysfs control 1)
. dlm-kernel starts gfs-kernel recovery (callback recover jid)
. dlm-kernel starts gfs-kernel (callback block 0)
next reply other threads:[~2011-10-13 14:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-13 14:20 David Teigland [this message]
2011-10-13 14:41 ` [Cluster-devel] cluster4 gfs_controld Steven Whitehouse
2011-10-13 15:30 ` David Teigland
2011-10-13 16:16 ` Steven Whitehouse
2011-10-13 16:49 ` David Teigland
2011-10-13 20:30 ` Lon Hohberger
2011-10-14 3:53 ` Fabio M. Di Nitto
2011-10-14 9:23 ` Andrew Beekhof
2011-10-13 15:02 ` Masatake YAMATO
2011-10-13 15:33 ` David Teigland
2011-10-13 19:00 ` Masatake YAMATO
2011-10-13 16:17 ` Steven Whitehouse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111013142059.GA6704@redhat.com \
--to=teigland@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.