Re: [Gluster-devel] compound fop design first cut

Changire" <milindchang...@gmail.com> > To: "Jeff Darcy" <jda...@redhat.com> > Cc: "Gluster Devel" <gluster-devel@gluster.org> > Sent: Friday, December 11, 2015 9:25:38 PM > Subject: Re: [Gluster-devel] compound fop design first cut > > >

Re: [Gluster-devel] compound fop design first cut

> 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

Re: [Gluster-devel] compound fop design first cut

On 12/09/2015 11:48 PM, Pranith Kumar Karampuri wrote: On 12/09/2015 08:11 PM, Shyam wrote: On 12/09/2015 02:37 AM, Soumya Koduri wrote: On 12/09/2015 11:44 AM, Pranith Kumar Karampuri wrote: On 12/09/2015 06:37 AM, Vijay Bellur wrote: On 12/08/2015 03:45 PM, Jeff Darcy wrote: On

Re: [Gluster-devel] compound fop design first cut

On Wed, Dec 9, 2015 at 8:02 PM, Jeff Darcy wrote: > > > > On December 9, 2015 at 7:07:06 AM, Ira Cooper (i...@redhat.com) wrote: > > 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 >

Re: [Gluster-devel] compound fop design first cut

Raghavendra Gowdappa" > <rgowd...@redhat.com>, "Ira Cooper" <i...@redhat.com> > Cc: "Gluster Devel" <gluster-devel@gluster.org> > Sent: Wednesday, December 9, 2015 11:44:52 AM > Subject: Re: [Gluster-devel] compound fop design first cut > > >

Re: [Gluster-devel] compound fop design first cut

Jeff Darcy 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

Re: [Gluster-devel] compound fop design first cut

uot;Gluster Devel" <gluster-devel@gluster.org> > Sent: Wednesday, December 9, 2015 5:37:05 PM > Subject: Re: [Gluster-devel] compound fop design first cut > > Jeff Darcy <jda...@redhat.com> writes: > > > However, I’d be even more comfortable with an eve

Re: [Gluster-devel] compound fop design first cut

On 12/09/2015 09:32 AM, Jeff Darcy wrote: On December 9, 2015 at 7:07:06 AM, Ira Cooper (i...@redhat.com) wrote: 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

Re: [Gluster-devel] compound fop design first cut

On December 9, 2015 at 7:07:06 AM, Ira Cooper (i...@redhat.com) wrote: > 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,

Re: [Gluster-devel] compound fop design first cut

On 12/09/2015 12:52 AM, Pranith Kumar Karampuri wrote: On 12/09/2015 10:39 AM, Prashanth Pai wrote: 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

Re: [Gluster-devel] compound fop design first cut

On 12/09/2015 02:37 AM, Soumya Koduri wrote: On 12/09/2015 11:44 AM, Pranith Kumar Karampuri wrote: On 12/09/2015 06:37 AM, Vijay Bellur wrote: On 12/08/2015 03:45 PM, Jeff Darcy wrote: On December 8, 2015 at 12:53:04 PM, Ira Cooper (i...@redhat.com) wrote: Raghavendra Gowdappa

Re: [Gluster-devel] compound fop design first cut

; Sent: Wednesday, December 9, 2015 2:18:47 PM > Subject: Re: [Gluster-devel] compound fop design first cut > > Geo-rep requirements inline. > > Thanks and Regards, > Kotresh H R > > - Original Message - > > From: "Pranith Kumar Karampuri"

Re: [Gluster-devel] compound fop design first cut

On 12/09/2015 08:11 PM, Shyam wrote: On 12/09/2015 02:37 AM, Soumya Koduri wrote: On 12/09/2015 11:44 AM, Pranith Kumar Karampuri wrote: On 12/09/2015 06:37 AM, Vijay Bellur wrote: On 12/08/2015 03:45 PM, Jeff Darcy wrote: On December 8, 2015 at 12:53:04 PM, Ira Cooper

Re: [Gluster-devel] compound fop design first cut

On 12/09/2015 08:08 PM, Shyam wrote: On 12/09/2015 12:52 AM, Pranith Kumar Karampuri wrote: On 12/09/2015 10:39 AM, Prashanth Pai wrote: 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

Re: [Gluster-devel] compound fop design first cut

Raghavendra Gowdappa writes: > From what I can see, new compound ops will _evolve_ in future based on > requirements unseen as of now. Yes, That is the one thing you can count on here ;) The compounding architecture proposed here, scares me to be honest. The complexity

Re: [Gluster-devel] compound fop design first cut

On December 8, 2015 at 12:53:04 PM, Ira Cooper (i...@redhat.com) wrote: > Raghavendra Gowdappa writes: > I propose that we define a "compound op" that contains ops. > > Within each op, there are fields that can be "inherited" from the > previous op, via use of a sentinel value. > > Sentinel

Re: [Gluster-devel] compound fop design first cut

On 12/09/2015 11:44 AM, Pranith Kumar Karampuri wrote: On 12/09/2015 06:37 AM, Vijay Bellur wrote: On 12/08/2015 03:45 PM, Jeff Darcy wrote: On December 8, 2015 at 12:53:04 PM, Ira Cooper (i...@redhat.com) wrote: Raghavendra Gowdappa writes: I propose that we define a "compound op"

Re: [Gluster-devel] compound fop design first cut

On 12/08/2015 03:45 PM, Jeff Darcy wrote: On December 8, 2015 at 12:53:04 PM, Ira Cooper (i...@redhat.com) wrote: Raghavendra Gowdappa writes: I propose that we define a "compound op" that contains ops. Within each op, there are fields that can be "inherited" from the previous op, via use

Re: [Gluster-devel] compound fop design first cut

On 12/09/2015 10:39 AM, Prashanth Pai wrote: 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

Re: [Gluster-devel] compound fop design first cut

On 12/09/2015 06:37 AM, Vijay Bellur wrote: On 12/08/2015 03:45 PM, Jeff Darcy wrote: On December 8, 2015 at 12:53:04 PM, Ira Cooper (i...@redhat.com) wrote: Raghavendra Gowdappa writes: I propose that we define a "compound op" that contains ops. Within each op, there are fields that can

Re: [Gluster-devel] compound fop design first cut

On 12/08/2015 09:02 AM, Pranith Kumar Karampuri wrote: On 12/08/2015 02:53 AM, Shyam wrote: Hi, Why not think along the lines of new FOPs like fop_compound(_cbk) where, the inargs to this FOP is a list of FOPs to execute (either in order or any order)? That is the intent. The question is

Re: [Gluster-devel] compound fop design first cut

> > On 12/08/2015 09:02 AM, Pranith Kumar Karampuri wrote: > > > > > > On 12/08/2015 02:53 AM, Shyam wrote: > >> Hi, > >> > >> Why not think along the lines of new FOPs like fop_compound(_cbk) > >> where, the inargs to this FOP is a list of FOPs to execute (either in > >> order or any order)? > >

[Gluster-devel] compound fop design first cut

hi, Draft of the design doc: Main motivation for the design of this feature is to reduce network round trips by sending more than one fop in a network operation, preferably without introducing new rpcs. There are new 2 new xlators compound-fop-sender, compound-fop-receiver.