On December 9, 2015 at 7:07:06 AM, Ira Cooper (i...@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.
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.
_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
