From: Jonathan E Brassow <jbrassow@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] New cluster mirror log implementation (RFC)
Date: Tue, 20 Jun 2006 21:17:04 -0500 [thread overview]
Message-ID: <9d5f7ddb761cad826cc70de465a70fac@redhat.com> (raw)
I've started on the rewrite for the cluster mirror log (can be found in
CVS head in cluster/cmirror-kernel). The purpose is to bring it inline
with the new CMAN/OpenAIS framework. Since this framework is now in
user-space, the cluster mirror log server implementation will exist in
user-space.
I've only worked on the client side (kernel) code so far. I plan to
use netlink to communicate requests from the client (kernel) to the
server (user-space). The server will be responsible for coordinating
cluster events, responding to client request, handling disk commits,
and notifying the kernel of any log device related failures.
The server will listen to requests from the client (netlink) and send
them to the rest of the cluster via OpenAIS. The results will be
replicated on each machine (running the server) with the server that
has the lowest cluster id responsible for committing the data to the
log device.
There are 17 types of client functions - most of which will need some
communication with the server. The input and output data varies. I
don't want to create unique structures to pass between the client and
server for each type of request, so right now I plan on passing generic
data. The server will interpret the data based on the request type.
The part I don't like about this plan is it requires both the client
and server to be able to interpret the data correctly without the help
of a header file... I can keep them in sync and check for version
mismatches during the log creation phase easily enough, but perhaps
there are better ideas.
Now that there are source files in-place, I'll try to submit patches to
this list before committing them. When I start work on the server
side, I'll probably do an initial commit and post patches thereafter
(unless people would prefer I submit the opening files here first).
brassow
For those that don't know: Logging implementations are modular and use
the APIs found in linux/drivers/md/dm-log.h. Primarily, the logging
implementations are used by device-mapper mirroring. Right now, there
are only single machine logging implementations in the kernel. Red Hat
has a cluster logging implementation for RHEL4 (cvs co -r RHEL4
cluster/cmirror-kernel), but since the upstream cluster infrastructure
is based on userspace CMAN/OpenAIS, that implementation will likely not
live outside of RHEL4.
next reply other threads:[~2006-06-21 2:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-21 2:17 Jonathan E Brassow [this message]
2006-06-21 3:57 ` [Cluster-devel] New cluster mirror log implementation (RFC) Steven Dake
2006-06-22 14:24 ` Lon Hohberger
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=9d5f7ddb761cad826cc70de465a70fac@redhat.com \
--to=jbrassow@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).