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. 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@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
