[Gluster-devel] Some questions about requisites of translators

[Anand Avati]

On Wed, May 2, 2012 at 3:55 AM, Xavier Hernandez <xhernandez at datalab.es>wrote:

> Hello,
>
> I'm wondering if there are any requisites that translators must satisfy to
> work correctly inside glusterfs.
>
> In particular I need to know two things:
>
> 1. Are translators required to respect the order in which they receive the
> requests ?
>
> This is specially important in translators such as performance/io-threads
> or caching ones. It seems that these translators can reorder requests. If
> this is the case, is there any way to force some order between requests ?
> can inodelk/entrylk be used to force the order ?
>
>
Translators are not expected to maintain ordering of requests. The only
translator which takes care of ordering calls is write-behind. After
acknowledging back write requests it has to make sure future requests see
the true "effect" as though the previous write actually completed. To that
end, it queues future "dependent" requests till the write acknowledgement
is received from the server.

inodelk/entrylk calls help achieve synchronization among clients (by
getting into a critical section) - just like a mutex. It is an arbitrator.
It does not help for ordering of two calls. If one call must strictly
complete after another call from your translator's point of view (i.e, if
it has such a requirement), then the latter call's STACK_WIND must happen
in the callback of the former's STACK_UNWIND path. There are no guarantees
maintained by the system to ensure that a second STACK_WIND issued right
after a first STACK_WIND will complete and callback in the same order.
Write-behind does all its ordering gimmicks only because it STACK_UNWINDs a
write call prematurely and therefore must maintain the causal effects by
means of queueing new requests behind the downcall towards the server.


> 2. Are translators required to propagate callback arguments even if the
> result of the operation is an error ? and if an internal translator error
> occurs ?
>
>
Usually no. If op_ret is -1, only op_errno is expected to be a usable
value. Rest of the callback parameters are junk.


> When a translator has multiple subvolumes, I've seen that some arguments,
> such as xdata, are replaced with NULL. This can be understood, but are
> regular translators (those that only have one subvolume) allowed to do that
> or must they preserve the value of xdata, even in the case of an internal
> error ?
>
>
It is best to preserve the arguments unless you know specifically what you
are doing. In case of error, all the non-op_{ret,errno} arguments are
typically junk, including xdata.



> If this is not a requisite, xdata loses it's function of delivering back
> extra information.
>
>
Can you explain? Are you seeing a use case for having a valid xdata in the
callback even with op_ret == -1?

Thanks,

Avati
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20120504/819d4018/attachment-0003.html>