Talk:Single system image

message: Can you explain in 50 words or less the relationship between "single system image" and "distributed operating system", as you see it? Pcap ping 17:18, 29 April 2010 (UTC)
thread_title:  Question 

message: Exactly 50 words, you may never know how difficult this was...
: The SSI is the user's perception of the transparency designed into DOS.
: The SSI is an extremely important illusion.
: Many difficult algorithms are required to impart transparency as a property of a DOS.
: Transparency is a difficult design-time implementation.  (Developer’s paradigm)
: The SSI is an important run-time illusion.  (User’s paradigm)
::I apologize for the (deleted) remark previously here.  It was intended to celebrate having been able to accomplish a statement in a reasonable space.  I later realized it could be viewed as goading and boorish.  It certainly was not.  Regards, JLSjr (talk) 23:17, 4 May 2010 (UTC)
thread_title: World-Class Effort

message: Well, it's time to be WP:BOLD, so I'm going to put my new article in place.  Let's see what fireworks this produces :-) HughesJohn (talk) 13:11, 2 October 2008 (UTC)
thread_title: Be Bold

message: Keep in mind: "The lead section, lead, or introduction of a Wikipedia article is the section before the table of contents and first heading. The lead serves both as an introduction to the article below and as a short, independent summary of the important aspects of the article's topic." HughesJohn (talk) 13:08, 2 October 2008 (UTC)
thread_title: Lead section

message: I have filled in the OpenVMS entries in the table.
I would like to discuss/suggest/add some additional aspects for SSI clusters:
===A Distributed Lock Manager===
Locking resources is cluster wide. Locks survive a node being removed from the cluster, regardless of whether that node was the master of the lock, or had some interest in the lock. Note that is some SSI system such as OpenVMS, the DLM is one of (if not the) fastest means of cluster communication.
===A single security model===
All security mechanisms are cluster wide. A single set of /etc/passwd or SYSUAF and related files are used.
===Kernel integrated===
The cluster software is directly integrated into the kernel. A standalone node is effectively a cluster of one node. Turning cluster software on or off is a configuration option not a re-install/rebuild. System services are mainly cluster centric. Cluster membership is present before normal file system and user access is possible. This also means before most daemons are possible.
===Cluster communication versus IPC===
Much if not most of the communication within the cluster is not specifically IPC. This is particularly true if the cluster software is fully integrated with the kernel, in which case most of the traffic is kernel to kernel, not specifically process to process. Thus we might use spinlocks for inter processor intra node coordination and communication, distributed lock manager for inter node kernel coordination and communication, and pipes for inter process communication.
Simon L Jackson (talk) 02:52, 11 January 2009 (UTC)
thread_title: Other Aspects

message: Much if not most of the communication within the cluster is not specifically IPC. This is particularly true if the cluster software is fully integrated with the kernel, in which case most of the traffic is kernel to kernel, not specifically process to process. Thus we might use spinlocks for inter processor intra node coordination and communication, distributed lock manager for inter node kernel coordination and communication, and pipes for inter process communication.
Simon L Jackson (talk) 02:52, 11 January 2009 (UTC)
thread_title: Cluster communication versus IPC

message: This is the ability to add or remove nodes at runtime, rather than at cluster start time.  I know that OpenSSI can do it, Kerrighed can't (but is working on it), not sure about others.  Somewhat important because it affects the purpose of the cluster:  Is it designed to be highly available, such that individual machines can fail but the cluster lives?  Or does adding additional systems increase performance but decrease reliability, since node failure means cluster failure?  Essentially the same kind of difference as (say) RAID-1 and RAID-0, respectively.
On a similar note, there's also the question of whether processes can live independently of their initial node.  In Mosix-based systems, one node may be doing the heavy lifting CPU-wise, but all I/O and IPC has to be proxied back to the starting node; if it fails, the process is dead.  By contrast, I believe OpenSSI tries to translate as many resources as it can to equivalent resources on the local machine, so only hardware-reliant processes die if the corresponding starter node dies.  This feature is obviously only relevant if a system supports hot removal, since if a node dies in (say) Kerrighed, your cluster is dead and the whole issue is moot.
Not sure if either or both of these warrant addition to the features section, some new section, and/or the grid. — Wisq (talk) 21:19, 16 September 2009 (UTC)
thread_title:  Hot node addition/removal? 

message: Curiously there are actually at least two clustering projects with this name, unrelated and both dead research projects. If someone wants to redo the row here are the refs for the two I found, wouldn't be surprised if there were more:
* http://dl.acm.org/citation.cfm?id=318988
* http://www.sciencedirect.com/science/article/pii/S0167819102000777
98.4.124.117 (talk) 06:33, 19 April 2017 (UTC)
thread_title:  GENESIS