Merging GFS2
The first one was asked by Andrew Morton: "why?". Given that OCFS2 is going in, does the kernel really need another clustered filesystem? What, in particular, does GFS bring that OCFS2 lacks? The answers took two forms: (1) Linux has traditionally hosted a large variety of filesystems, and (2) since cluster filesystems are relatively new, users should be able to try both and see which one works better for them. David Teigland also posted a list of GFS features.
GFS will probably win this argument; there is a clear user community, and filesystems tend not to have any impact on the rest of the kernel. But, still, some developers are starting to wonder; consider, for example, this message from Suparna Bhattacharya:
The other issue which came up was the creation of a user-space API for the distributed lock manager (DLM) used by GFS. If nothing else, the two cluster filesystem should have a common API so that applications can be written for either one. One option for this API might be "dlmfs", a virtual filesystem used with OCFS2. The dlmfs approach allows normal filesystem operations to be used for lock management tasks; even shell scripts can perform locking. Concerns with dlmfs include relatively slow performance and a certain unease with aspects of the interface:
(Andrew Morton).
It is not clear that better alternatives exist, however. One could implement it all with a big set of ioctl() calls, but nobody really wants to do that. Another approach would be to create a new set of system calls specifically for lock management. Some have argued in favor of system calls, but others, such as Alan Cox, are strongly opposed:
Alan lists a number of reasons why a file descriptor-based approach makes sense for this sort of operation - they mostly come down to well-understood semantics and the fact that many things just work.
This is clearly a discussion which could go on for some time. Daniel
Phillips points out that this is not
necessarily a problem. There are currently no user-space users of any DLM
API beyond a few filesystem management tools, so there is no great hurry to
merge any API. The cluster filesystems could go in without any user-space
DLM interface at all while the developers figure out what that interface
should be. And, says Daniel, perhaps there should not be one at all.
Despite the perceived elegance of having a single lock manager on the
system, having user space rely upon its own, user-space DLM is a workable
solution which could simplify the kernel side of things.
| Index entries for this article | |
|---|---|
| Kernel | Clusters/Filesystems |
| Kernel | Distributed lock management |
| Kernel | Filesystems/Cluster |
| Kernel | GFS |