[Gluster-devel] compound fop design first cut

[Shyam]

On 12/09/2015 09:32 AM, Jeff Darcy wrote:
>
>
>
> On December 9, 2015 at 7:07:06 AM, Ira Cooper (ira at redhat.com) wrote:
>> A simple "abort on failure" and let the higher levels clean it up is
>> probably right for the type of compounding I propose. It is what SMB2
>> does. So, if you get an error return value, cancel the rest of the
>> request, and have it return ECOMPOUND as the errno.
>
> This is exactly the part that worries me.  If a compound operation
> fails, some parts of it will often need to be undone.  “Let the higher
> levels clean it up” means that rollback code will be scattered among all
> of the translators that use compound operations.  Some of them will do
> it right.  Others . . . less so.  ;)  All willl have to be tested
> separately.  If we centralize dispatch of compound operations into one
> piece of code, we can centralize error detection and recovery likewise.
> That ensures uniformity of implementation, and facilitates focused
> testing (or even formal proof) of that implementation.

My take on this, is whichever layer started the compounding takes into 
account the error handling. I do not see any requirement for undoing 
things that are done, and would almost say (without further thought 
(that's the gunslinger in me talking ;) )) that this is not supported as 
a part of the compounding.

>
> Can we gain the same benefits with a more generic design?  Perhaps.  It
> would require that the compounding translator know how to reverse each
> type of operation, so that it can do so after an error.  That’s
> feasible, though it does mean maintaining a stack of undo actions
> instead of a simple state.  It might also mean testing combinations and
> scenarios that will actually never occur in other components’ usage of
> the compounding feature.  More likely it means that people will *think*
> they can use the facility in unanticipated ways, until their
> unanticipated usage creates a combination or scenario that was never
> tested and doesn’t work.  Those are going to be hard problems to debug.
> I think it’s better to be explicit about which permutations we actually
> expect to work, and have those working earlier.

Jeff, a clarification, are you suggesting fop_xxx extensions for each 
compound operation supported?
Or,
Suggesting a *single* FOP, that carries compounded requests, but is 
specific about what requests can be compounded? (for example, allows 
open+write, but when building out the compound request, disallows *say* 
anything else)

(If any doubt, I am with the latter and not so gaga about the former as 
it explodes the FOP list)

Also, I think the compound list has exploded (in this mail conversation) 
and provided a lot of compounding requests... I would say this means we 
need a clear way of doing the latter.

> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>

P.S: Ignore this...
gunslinger: "a man who carries a gun and shoots well." I claim to be 
neither... just stating