lkml.org 
[lkml]   [2005]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: GFS, what's remaining
Date
On Friday 02 September 2005 17:17, Andi Kleen wrote:
> The only thing that should be probably resolved is a common API
> for at least the clustered lock manager. Having multiple
> incompatible user space APIs for that would be sad.

The only current users of dlms are cluster filesystems. There are zero users
of the userspace dlm api. Therefore, the (g)dlm userspace interface actually
has nothing to do with the needs of gfs. It should be taken out the gfs
patch and merged later, when or if user space applications emerge that need
it. Maybe in the meantime it will be possible to come up with a userspace
dlm api that isn't completely repulsive.

Also, note that the only reason the two current dlms are in-kernel is because
it supposedly cuts down on userspace-kernel communication with the cluster
filesystems. Then why should a userspace application bother with a an
awkward interface to an in-kernel dlm? This is obviously suboptimal. Why
not have a userspace dlm for userspace apps, if indeed there are any
userspace apps that would need to use dlm-style synchronization instead of
more typical socket-based synchronization, or Posix locking, which is already
exposed via a standard api?

There is actually nothing wrong with having multiple, completely different
dlms active at the same time. There is no urgent need to merge them into the
one true dlm. It would be a lot better to let them evolve separately and
pick the winner a year or two from now. Just think of the dlm as part of the
cfs until then.

What does have to be resolved is a common API for node management. It is not
just cluster filesystems and their lock managers that have to interface to
node management. Below the filesystem layer, cluster block devices and
cluster volume management need to be coordinated by the same system, and
above the filesystem layer, applications also need to be hooked into it.
This work is, in a word, incomplete.

Regards,

Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-09-03 07:58    [W:1.286 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site