Re: compound fop design first cut

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 1) fops will be compounded per inode, meaning 2 fops on different
> inodes can't be compounded (Not because of the design, Just reducing
> scope of the problem).
>
> 2) Each xlator that wants a compound fop packs the arguments by
> itself.

Packed how?  Are we talking about XDR here, or something else?  How is
dict_t handled?  Will there be generic packing/unpacking code somewhere,
or is each translator expected to do this manually?

> 3) On the server side a de-compounder placed below server xlator
> unpacks the arguments and does the necessary operations.
>
> 4) Arguments for compound fops will be passed as array of union of
> structures where each structure is associated with a fop.
>
> 5) Each xlator will have <xlator>_compound_fop () which receives the
> fop and does additional processing that is required for itself.

What happens when (not if) some translator fails to provide this?  Is
there a default function?  Is there something at the end of the chain
that will log an error if the fop gets that far without being handled
(as with GF_FOP_IPC)?

> 6) Response will also be an array of union of response structures
> where each structure is associated with a fop's response.

What are the error semantics?  Does processing of a series always stop
at the first error, or are there some errors that allow retry/continue?
If/when processing stops, who's responsible for cleaning up state
changed by those parts that succeeded?  What happens if the connection
dies in the middle?

How are values returned from one operation in a series propagated as
arguments for the next?

What are the implications for buffer and message sizes?  What are the
limits on how large these can get, and/or how many operations can be
compounded?

How is synchronization handled?  Is the inode locked for the duration of
the compound operation, to prevent other operations from changing the
context in which later parts of the compound operation execute?  Are
there possibilities for deadlock here?  Alternatively, if no locking is
done, are we going to document the fact that compound operations are not
atomic/linearizable?
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel



[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux