Hi, while the erasure code xlator is being reviewed, I'm thinking about how to handle some kinds of errors. In normal circumstances all bricks will give the same answers to the same requests, however, after some brick failures, underlying file system corruption or any other factors, it's possible that bricks give different answers to the same request. For example, an 'unlink' request could succeed on some bricks and fail on others. Currently, the most "common" answer is taken as the good one only if it reaches a minimum amount of quorum, but if there isn't enough quorum, it fails with EIO. Not having enough quorum means that more than R (redundancy) bricks have failed simultaneously (or have failed while another brick was alive but not recovered yet), which means that it's outside of the defined work conditions. However in some circumstances this could be improved. Supose that the reason of failure of the unlink operation on some brick is ENOENT. We could consider this answer as a success and combine it with the other successful answers, giving more chances to reach the quorum minimum. Of course this will depend on the operation. If the operation were an open instead of an unlink, this combination won't be possible. This can also be applied to error codes. In the same case, ENOENT and ENOTDIR errors could be combined, because they basically mean the same (relative to the file in question). Even in an open operation these two answers could be combined to give a more detailed error instead of EIO. The only possible combinations I see are: * Coalesce an error answer with a success answer * Coalesce two different error answers I don't see any case where two different success answers could be combined. Would this be interesting to have for ec ? Any thoughts/ideas/feedback will be welcome. Xavi _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
