> 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
