[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [ldapext] nfsv4 vs the ldap consistency model



On Mon, 2008-11-24 at 13:30 +0100, Leif Johansson wrote:
> >
> > Leif,
> > may I insist in asking what do they need this feature for ?
> >
> > Simo.
> 
> 
> They want to use LDAP as a volume location service for NFS (aka NSDB). 
> LDAP would be used to keep track of location replicated copies of file-sets. 
> The LDAP consistency model implies that a two clients could see different 
> views of the filesystem depending on which LDAP replica the client was
> looking at.
> 
> In AFS this function is implemented by something called VLDB which is 
> backed by a distributed databased 'ubik'. By comparison ubiq uses a 
> strict consistency model where if an update doesn't reach one of the
> replicas further updates are forbidden until the replica is brought back
> in sync with the others (this is called that the cell has lost quorom).
> 	
> It could be that "federated nfsv4" doesn't actually need the type of 
> consistency model that is needed by other distributed fs:en (eg AFS)
> in which case this may be an unnecessary discussion... 

A system that enforce all components to be online 100% of the time does
not seem very useful in the general case.
For LDAP servers, the point of having multiple masters and replicas is
also that most applications can continue to work even when the network
splits.

I think many users of a "federated nfsv4" setup would like the same
characteristics if at all possible. But it is up to them.

The problem with requiring LDAP servers to synchronize is that you have
no assurance all LDAP servers are working in unison. In some
organization LDAP proxies are used to separate networks or to filter
information, and they sometimes use caches to manage the load. In this
case even if the "core" set of master and slaves is synchronized, these
proxies may be not.
Although, I guess, you can put the restriction that the nfsv4 deployment
must point only to servers that can communicate to each other.

In any case putting the burden to check for synchronization on the
reader is certainly a much easier approach than trying to modify all
existing LDAP server implementations, unless you want to corner the
users of nfsv4 to be able to use only some specific implementation
potentially for many years.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo@samba.org>
Senior Software Engineer at Red Hat Inc. <simo@redhat.com>

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext