Re: Persistence of completed_requests in sessionmap (do we need it?)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Just forwarding the replies to the list as it looks like it got blocked due to accidental HTML.
-Greg


> On Mar 4, 2015, at 6:20 AM, John Spray <john.spray@xxxxxxxxxx> wrote:
> 
> On 04/03/2015 12:14, 严正 wrote:
>> 
>>> 在 2015年3月4日,05:39,John Spray <john.spray@xxxxxxxxxx> 写道:
>>> 
>>> During replay, we rebuild completed_requests from EMetaBlob::replay, and we've made it this far without reliably persisting it in sessionmap, so I wonder if we ever needed to save this at all? Thoughts?
>> 
>> I think we need to save completed_requests for corner cases. consider following scenario:
>> 
>> Client A sends setattr request to MDS
>> MDS handles the request and sends reply to client. But network between MDS and client A becomes disconnected.
>> MDS handles lots of setattr requests from other clients. Log entry for the first setattr request get trimmed
>> MDS crashed, standby MDS on other host takes over.
>> Client A re-send the setattr request to the new MDS.
> Ah, this makes sense.  I suspect we never saw that scenario in the automated tests because they almost all just use a single client.
> 
> John
> 

--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux