Re: Clusterwide pids

["Albert D. Cahalan" <acahalan@cs.uml.edu>]

Lars Marowsky-Br\351e writes:
>    "Albert D. Cahalan" <acahalan@cs.uml.edu> said:

>>> This leaves us with the chicken and egg problem - how do you
>>> boot a node which is - at the time of boot - unable to contact
>>> the cluster?
>>
>> You don't. It is a mistake to design for this perversion.
>
> Uh. A node not being able to join the cluster is a perfectly
> reasonable exception, and you want it to boot so that you can
> fix it over the network. It makes sense not to start any cluster
> services, that is true.

1. boot the single node without joining the cluster
2. fix the node
3. reboot to join the cluster

>> Do you, or do you not want a shared PID space? Make up your
>> mind about this. You don't run an SMP system as multiple
>> uniprocessor systems, then suddenly decide that you want SMP!
> 
> Refer to the CPU hotplug features in recent 2.4 kernels ;-)

When the CPU is added, it does not bring its own kernel state.
The CPU would generally start from reset or equivalent.
This is not a problem. It's like rebooting a node when you want
that node in the cluster.

Running a 2-way system with 2 GB of RAM and 2 copies of the
kernel, you can't get to SMP without killing some processes.
One of the CPUs has to be reset, more-or-less.

>> Now what am I supposed to do with the "ps" program I wrote?
>> Invisible processes? Nope, not at all OK. This is crap too:
>> 
>>   PID TTY          TIME CMD
>>     1 ?        00:00:03 init
>>     1 ?        00:00:03 init
>>     1 ?        00:00:03 init
>>     1 ?        00:00:03 init
>
> You won't see this.
>
> init is almost guaranteed to be a "local" process, and thus
> not visible to other nodes.

Eeew.

Share, or do not share.


Linux-cluster: generic cluster infrastructure for Linux
Archive:       http://mail.nl.linux.org/linux-cluster/