On Thu, 2004-10-07 at 12:35, Daniel Phillips wrote: > On Thursday 07 October 2004 02:07, David Teigland wrote: > > - SM is almost exclusively designed for symmetric clustering > > subsystems and almost exclusively for in-kernel use. > > Hi Dave, > > The executive summary of your post is "my pristine, perfect service > manager is for symmetric systems only and keep yer steenking > client-server mitts away from it." > > You may well be right that it is not suited to the task at hand. My > interest was more in its notion of layered services than its > membership-oriented control methods and events (by the way, the > stop-start-finish terminology is still horribly broken, I thought you > were going to fix that). > > > the server is by definition a single point of failure (something > > absent from symmetric systems.) > > No. The csnap server is not a single point of failure any more than a > DLM lock master is. So either it is not a single point of failure, or > single points of failure are not absent from your gdlm, choose your > poison. > > > A prime example is NFS. RM is able to monitor an NFS server and start > > it on another machine if it fails. NFS is probably the model you > > should follow if your system is asymmetric and you want to use RM. > > NFS is an awful model. It keeps almost all its state on the clients, > and it tries to inhale the entire recovery model into itself, with no > help from infrastructure. > > In contrast, a csnap server keeps almost all its state persistently on > shared storage, and it is supposed to have a cluster infrastructure > around to help it do some global processing that is not appropriate for > it to undertake itself. You seem to be arguing passionately that yours > is not the infrastructure we are looking for. Fair enough, I'd hoped > for more. Daniel, Maybe you should describe what kind of help you are looking for from the infrastructure? Daniel
