From: shearerje_at_comcast.net
Date: Wed Feb 25 2004 - 16:03:41 PST
Porcupine implements a scaleable mail service that borrows heavily from the philosophy presented by Fox et al in “Cluster-Based Scaleable Network Services” with two very critical differences: (1) the Fox architecture supported a variety of different services and so needed proxies to provide a common interface to its Scaleable Network Service layer while Porcupine is offering only a mail service, (2) the services offered by the Fox architecture were in general information pass-through services such as web searching while Porcupine supports storage of client information with every transaction. Not surprisingly, much of the Porcupine paper focuses on issues associated with reliable storage and retrieval of client-specific information and mail.
Data was categorized as “hard state” data that must be maintained in stable storage, and “soft state” data that is only resident and can be reconstructed after a crash. User mail is stored in hard state mailbox fragments that are located via a mailbox fragment list. This looks to me like the application level equivalent of file system “segments” and “inodes”. I was surprised that the fragment list is “soft state” until I read how it is reconstructed after failure by finding and collating the fragment locations much the way disk repair software can locate file segments and rebuild the inode. I felt that the paper underplayed the dependency of the system on the expectation that mail is created and destroyed but rarely modified. This expectation allows Porcupine to ignore a lot of the “copy invalidation” issues associated with replicated data in other parallel processing systems.
I was impressed that the system, billed as dynamically allocated, behaves like a statically allocated system (i.e., efficiently) until there is a failure or load balance issue, and then it dynamically handles it before settling back into a static behavior.
For all Porcupine’s promise, I was infuriated by the assertion (section 1.2) that “its underlying services and architecture are appropriate for other systems in which data is frequently written and good performance, availability, and manageability at high volume are demanded.” That is way too broad. It is not suitable for just any write-intensive task. Porcupine (and the Fox architecture) is tailored for simultaneously handling large numbers of small independent tasks. It is not suitable for tasks such as weather prediction or fluid dynamics in which the individual tasks must closely interact. The assertion added no value, was not defended, and should have been left out.
This archive was generated by hypermail 2.1.6 : Wed Feb 25 2004 - 16:03:47 PST