Re: [ldapext] nfsv4 vs the ldap consistency model

[Howard Chu <hyc@highlandsun.com>]

> > Then my answer is (a) and (b).

> > You cannot guarantee that the update will succeed at all slaves, so
> > abort/rollback is essential.

> So how is this different from the model we have today - only today you
> will never find out if updates fail on any of your slaves!?

Don't confuse the issue. The model we have today is irrelevant to the 
discussion; you started this thread with the criterion that the result of an 
update be delayed until it is completed on all slaves. My point is that you 
cannot fulfill this requirement without abort/rollback capability.

Whether or how any particular server can actually determine the definitive 
outcome of the update is a completely separate question. Simo already noted 
some problems in that area; the entire question is too poorly thought out to 
even begin addressing it here. (Cart before the horse...)

If you acknowledge that the feature you're asking for is in fact a distributed 
transaction (which it very obviously is) then we may at least know that you 
(generic "you" / NFS wg) understand the problem well enough to start 
discussing solutions. Without that basic level of understanding, it's simply a 
waste of time.
--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext