Parallel File System vs. REST/SOAP

By Henry Newman

I have gotten a lot of feedback from people in the parallel file system community my article on cloud computing's impact on file systems. All of the feedback has been positive, but a number of people pointed out that I should have also discussed file systems that support a single namespace but not parallel I/O to a single file. I like to call these "shared file systems."

It is likely easier for these file systems to deal with the POSIX atomicity issues, but they still face many of the same problems with POSIX and file system metadata requirements as file systems that support parallel I/O do.

The vendor community that controls the standard does not want to add anything, so what are we to do as?

The other option besides adding things is to relax the requirements. Since adding new features seems to be out of the question, how about relaxing the current requirements?

Maybe we could have a mount option that doesn't have the same metadata atomicity requirements. File systems that are NFS mounted have in the past had different metadata atomicity requirements than the server file system. Maybe we should use this model as an option for shared and parallel file systems.

Clearly, this is not up to me but up to those people and companies that have paid to be part of the OpenGroup and part of the standards process. If these people are reading this blog entry, please consider this. Without some changes, I fear that the REST/SOAP interface might make the POSIX file system go the way of the dodo bird, which went extinct because of human decisions.

This article was originally published on May 23, 2013