[Gluster-devel] compound fop design first cut

[Rajesh Joseph]

----- Original Message -----
> From: "Ira Cooper" <ira at redhat.com>
> To: "Jeff Darcy" <jdarcy at redhat.com>, "Raghavendra Gowdappa" <rgowdapp at redhat.com>, "Pranith Kumar Karampuri"
> <pkarampu at redhat.com>
> Cc: "Gluster Devel" <gluster-devel at gluster.org>
> Sent: Wednesday, December 9, 2015 5:37:05 PM
> Subject: Re: [Gluster-devel] compound fop design first cut
> 
> 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.
> 

I agree with Ira here. This problem is already addressed by NFS and SMB.
So instead of reinventing the wheel lets pick the best bits from these
solutions and incorporate in Gluster.

>From multi-protocol point of view we like to compound operations like
open + set_leaseID + lk and many more. With the current approach it would 
be really messy to have separate functions for each such combinations and a 
dedicated translator to handle them.

As others have mentioned I think it would be better to have a general
fop (fop_compound) which can handle compound fop. Each translator can
choose to implement it or not. Each translator can take a decision 
whether to compound more fops or de-compound them. e.g. currently
you can make the protocol server de-compound all the compound fops.

-Rajesh

> My thoughts,
> 
> -Ira
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel