> The reason for this is that there is more than synchronizing locks. It is > also necessary to synchronize inode status and data. It is a requirement > that a change anywhere in the file be instantaneously (atomicly) reflected > in all other members in the cluster. This requires an *extremely* complex > series of semaphores. As far as I know CFS on TOPS-20 is the *only* > implementation to have gotten it right (although VMS clusters may also > have done so).
I'd think there are already many filesystems capable of that, although most probably are commercial. Except recently RedHat released GFS as open source which should be able to do that. We've looked at GFS and although they released it open source you still have to pay for it. It might as well be commercial. Lustre Lite is the only free solution we've found that boasts the same functionality as GFS. That is why we think it will work for IMAP. Another part of our problem is that because IMAP is value-added to our automated web-hosting software, the http servers also need access to the data store in order to create the email accounts. Our spam filter needs access in order to run salearn and update the bayes db, so putting IMAP on the local file system (because of the mentioned limitation) would require that each of our servers run: SMTP, POP, IMAP, salearn, create_mail daemon, and that the webmail server, and the web access to create email accounts have their software changed to look up the location of each of the users before the requests are made. This would also mean that our POP servers be configured with a public IP Address or installed with a "pop Proxy" In order that users could retrieve mail from the same data store using POP. If we put IMAP's data on a Lustre data store it should perform similar to how GFS does and we'll be able to access the same data whether it is from the web hosting service, webmail, or a system dedicated to spam and virus scanning. The simple fact of the matter is, if we were successfully able to implement IMAP's data store with Lustre it would be much more scalable with a lot less development of "middleware" software to do user lookups serving separate (and growing) services. Hopefully we can leave to the filesystem people to their job and trust that they are able to make a remote distributed file system act as if it were a local file system and provide enough I/O to get the job done. I'm confident that if Lustre does what it says it should work with IMAP just like IMAP works over a local volume. I'm still skeptical that they can boast this, but if it turns out that IMAP won't work over Lustre I would suggest that IMAP server developers and file system developers alike try to figure out a way to get IMAP POP SMTP etc file locking working over a similar distributed file system. For the reasons mentioned above I feel that many would find that useful.
