----- Original Message ----- > From: "Ira Cooper" <ira@xxxxxxxxxx> > To: "Jeff Darcy" <jdarcy@xxxxxxxxxx>, "Raghavendra Gowdappa" <rgowdapp@xxxxxxxxxx>, "Pranith Kumar Karampuri" > <pkarampu@xxxxxxxxxx> > Cc: "Gluster Devel" <gluster-devel@xxxxxxxxxxx> > Sent: Wednesday, December 9, 2015 5:37:05 PM > Subject: Re: compound fop design first cut > > Jeff Darcy <jdarcy@xxxxxxxxxx> 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@xxxxxxxxxxx > http://www.gluster.org/mailman/listinfo/gluster-devel _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
