Re: [PATCH 04/39] mds: make sure table request id unique

2013-03-29 Thread Gregory Farnum
This looks good to me and Sage liked the shape of it. Reviewed-by: Greg Farnum We do still need to update the mds protocol version, and I'd like to switch over the messages that are already changed to the new encoding system at the same time. I'm happy to do all that but will wait to hear back ab

Re: [PATCH 04/39] mds: make sure table request id unique

2013-03-25 Thread Yan, Zheng
On 03/22/2013 06:03 AM, Gregory Farnum wrote: > Right. I'd like to somehow mark those reqid's so that we can tell when > they come from a different incarnation of the MDS TableClient daemon. > One way is via some piece of random data that will probably > distinguish them, although if we have someth

Re: [PATCH 04/39] mds: make sure table request id unique

2013-03-21 Thread Gregory Farnum
On Thu, Mar 21, 2013 at 1:07 AM, Yan, Zheng wrote: > On 03/21/2013 02:31 AM, Greg Farnum wrote: >> On Tuesday, March 19, 2013 at 11:49 PM, Yan, Zheng wrote: >>> On 03/20/2013 02:15 PM, Sage Weil wrote: On Wed, 20 Mar 2013, Yan, Zheng wrote: > On 03/20/2013 07:09 AM, Greg Farnum wrote: >>>

Re: [PATCH 04/39] mds: make sure table request id unique

2013-03-21 Thread Yan, Zheng
On 03/21/2013 02:31 AM, Greg Farnum wrote: > On Tuesday, March 19, 2013 at 11:49 PM, Yan, Zheng wrote: >> On 03/20/2013 02:15 PM, Sage Weil wrote: >>> On Wed, 20 Mar 2013, Yan, Zheng wrote: On 03/20/2013 07:09 AM, Greg Farnum wrote: > Hmm, this is definitely narrowing the race (probably en

Re: [PATCH 04/39] mds: make sure table request id unique

2013-03-20 Thread Greg Farnum
On Tuesday, March 19, 2013 at 11:49 PM, Yan, Zheng wrote: > On 03/20/2013 02:15 PM, Sage Weil wrote: > > On Wed, 20 Mar 2013, Yan, Zheng wrote: > > > On 03/20/2013 07:09 AM, Greg Farnum wrote: > > > > Hmm, this is definitely narrowing the race (probably enough to never > > > > hit it), but it's no

Re: [PATCH 04/39] mds: make sure table request id unique

2013-03-19 Thread Yan, Zheng
On 03/20/2013 02:15 PM, Sage Weil wrote: > On Wed, 20 Mar 2013, Yan, Zheng wrote: >> On 03/20/2013 07:09 AM, Greg Farnum wrote: >>> Hmm, this is definitely narrowing the race (probably enough to never hit >>> it), but it's not actually eliminating it (if the restart happens after 4 >>> billion re

Re: [PATCH 04/39] mds: make sure table request id unique

2013-03-19 Thread Yan, Zheng
On 03/20/2013 02:15 PM, Sage Weil wrote: > On Wed, 20 Mar 2013, Yan, Zheng wrote: >> On 03/20/2013 07:09 AM, Greg Farnum wrote: >>> Hmm, this is definitely narrowing the race (probably enough to never hit >>> it), but it's not actually eliminating it (if the restart happens after 4 >>> billion re

Re: [PATCH 04/39] mds: make sure table request id unique

2013-03-19 Thread Sage Weil
On Wed, 20 Mar 2013, Yan, Zheng wrote: > On 03/20/2013 07:09 AM, Greg Farnum wrote: > > Hmm, this is definitely narrowing the race (probably enough to never hit > > it), but it's not actually eliminating it (if the restart happens after 4 > > billion requests?). More importantly this kind of symp

Re: [PATCH 04/39] mds: make sure table request id unique

2013-03-19 Thread Yan, Zheng
On 03/20/2013 07:09 AM, Greg Farnum wrote: > Hmm, this is definitely narrowing the race (probably enough to never hit it), > but it's not actually eliminating it (if the restart happens after 4 billion > requests…). More importantly this kind of symptom makes me worry that we > might be papering

Re: [PATCH 04/39] mds: make sure table request id unique

2013-03-19 Thread Greg Farnum
Hmm, this is definitely narrowing the race (probably enough to never hit it), but it's not actually eliminating it (if the restart happens after 4 billion requests…). More importantly this kind of symptom makes me worry that we might be papering over more serious issues with colliding states in

[PATCH 04/39] mds: make sure table request id unique

2013-03-17 Thread Yan, Zheng
From: "Yan, Zheng" When a MDS becomes active, the table server re-sends 'agree' messages for old prepared request. If the recoverd MDS starts a new table request at the same time, The new request's ID can happen to be the same as old prepared request's ID, because current table client assigns req