On 12/09/2015 09:32 AM, Jeff Darcy wrote:
On December 9, 2015 at 7:07:06 AM, Ira Cooper (ira@xxxxxxxxxx) 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@xxxxxxxxxxx
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
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
