[Gluster-devel] compound fop design first cut

[Ira Cooper]

Jeff Darcy <jdarcy at redhat.com> writes:

> However, I’d be even more comfortable with an even simpler approach that
> avoids the need to solve what the database folks (who have dealt with
> complex transactions for years) would tell us is a really hard problem.
> Instead of designing for every case we can imagine, let’s design for the
> cases that we know would be useful for improving performance.  Open plus
> read/write plus close is an obvious one.  Raghavendra mentions
> create+inodelk as well.  For each of those, we can easily define a
> structure that contains the necessary fields, we don’t need a
> client-side translator, and the server-side translator can take care of
> “forwarding” results from one sub-operation to the next.  We could even
> use GF_FOP_IPC to prototype this.  If we later find that the number of
> “one-off” compound requests is growing too large, then at least we’ll
> have some experience to guide our design of a more general alternative.
> Right now, I think we’re trying to look further ahead than we can see
> clearly.

Actually, I'm taking the design, I've seen another network protocol use,
SMB2, and proposing it here, I'd be shocked if NFS doesn't behave in the
same way.

Interestingly, all the cases, really deal with a single file, and a
single lock, and a single...

There's a reason I talked about a single sentinel value, and not
multiple ones.  Because I wanted to keep it simple.  Yes, the extensions
you mention are obvious, but they lead to a giant mess, that we may not
want initially.  (But that we CAN extend into if we want them.  I made
the choice not to go there because honestly, I found the complexity too
much for me.)

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.

Note: How you keep the list to be compounded doesn't matter much to me.
the semantics matter, because those are what I can ask for later, and
allow us to create ops the original desginers hadn't thought of, which
is usually the hallmark of a good design.

I think you should look for a simple design you can "grow into" instead
of creating one off ops, to satisfy a demand today.

My thoughts,

-Ira