[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] mirroring: [patch 1 of 8] device failure tolerance




On Jun 30, 2005, at 11:38 AM, Greg Freemyer wrote:

On 6/30/05, Jonathan E Brassow <jbrassow redhat com> wrote:

On Jun 30, 2005, at 10:13 AM, Greg Freemyer wrote:

On 6/29/05, Jonathan E Brassow <jbrassow redhat com> wrote:
This patch defines a couple more states that logs can return, and
checks for those states in the mirror code. The states are useful for
logs that have cluster support.


brassow

Have I been asleep? This is the first I heard of DM having cluster mirror support. I assume the goal is something along the lines of what DRBD provides.

Can someone give a very high-level overview of current status, plans,
etc. related to DM Cluster Mirror support. And if this related to the
DRBD project?

Please note that the "mirroring [patch x of 8]..." set for device fault
tolerance has been replaced with the "mirroring [patch x of 6]..." set.


The cluster mirroring that I'm talking about is active/active and
capable of handling more than 2 nodes. It would be used in conjunction
with a clustered file system - like GFS. The application sitting on
the cluster mirror should be cluster-aware. You wouldn't be able to
just put ext3 on there and expect it to work in a cluster capacity.


Although there are some minor things that need to happen in the mirror
proper code (as can be seen from the smallness of the cluster patch),
the heavy lifting is done by a cluster-aware log. That is were you are
keeping track of clean/dirty/recovering state.


An out-dated (but still useful for background) dock can be found at
http://www.brassow.com/mirroring/index.html

  brassow


Sounds like you have more ambitious plans than DRBD. (They have active-passive now and IIRC they plan the next major release to have active-active, but I think only on 2 nodes.)

Is the GFS team planning on supporting this infrastructure.  I hope so.


Yes. In fact, the cluster log being developed leverages the Red hat cluster manager (cman) - the same one that GFS uses.


CMAN is moving to user space (I think in the FC5 timeframe?), so the cluster log will have to adapt to that. I won't be submitting the cluster log code until that takes place. It is available in the cluster repository though (sources.redhat.com/cluster), but i will have to clean it up again to take advantage of the hooks I added to the logging code.

 brassow


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]