[Linux-cluster] Re: Csnap server cluster membership interface

[Daniel Phillips]

On Wednesday 20 October 2004 17:53, Benjamin Marzinski wrote:
> I think I am having a terminology issue here.
>
> If you do a dmsetup to create a csnap device with (for example)
> /dev/sda1 as the origin and /dev/sda2 as the snapstore, and do
> another dmsetup to create a csnap device with /dev/sdb1 as the origin
> and /dev/sdb2 as the snapstore, then you have two.... what?
>
> csnap devices?

Two virtual csnap devices.

> physical snapshot+origin devics in the device mapper stack?

Two physical snapshot+origin pairs.

> For the sake of future discussions, it would be really nice to have
> concrete terms to the things that the dmsetup gives you (possibly
> csnap devices) and the things the csnap-create gives you (possibly
> virtual snapshot devices).
>
> If you have concrete names for these 
> things, tell me, and I'll use them. If not, pick some, so that we
> agree.

The thing dmsetup gives you is a "virtual device" because device mapper 
invents it using the underlying "physical" devices (which may 
themselves be virtual devices, just to confuse things).  I say "virtual 
csnap device" when I want to be unambiguous, and we have both "origin 
virtual csnap device" and 64 possible flavors of "snapshot virtual 
csnap device".

The thing csnap-create creates by writing onto a "physical" device may 
deserve a name, something like meta-device, because it supports N 
distinct virtual devices on top of it.  Currently, I just call it a 
snapshot store, though I've sometimes thought about inventing the
term "metadevice".

I refer to the underlying devices as "physical" devices (complete with 
quotes), and we can unambiguously talk about the snapshot store (better 
than talking about the "snapshot origin" because that gets confused 
with the origin virtual device, and eventually we will allow snapshot 
stores with no origins).

> Otherwise, as long as we are ignoring the case where you have
> multiple csnap devices (a term I use as suggested in the last
> paragraph), and hence, multiple agents, the idea makes sense.

I'd hope it makes sense even if we don't ignore the multiple snapshot 
stores case.  It comes down to a question of the addressing scheme for 
our cluster control messages, do we implement the scheme in the agents, 
or in cman?  We could for instance have cman hand out a port for the 
agent to listen on along with instantiating a service group, giving us 
a way to message by node:service (analogous to address:port).  I just 
think it's a good idea to try out the simple case first, then have the 
benefit of experience in settling on a nice addressing scheme.  As 
you've noticed, it's easy to get tangled up in terminology, and the 
number of different flavors of "multiple" we've got is already 
intimidating.

One thing we don't want to do is require all the servers for multiple 
snapshot stores to be on the same node, so far there is no such 
requirement.

Regards,

Daniel