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

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

[John Spray]

Zheng noticed on my new sessionmap code [1] that sessions weren't 
getting dirtied on trim_completed_requests.  I had missed that, because 
I was only updating the places that we already incremented the 
sessionmap version while modifying something.

I went and looked at how this worked in the existing code, and it 
appears that we don't actually bother persisting updates to the 
sessionmap if completed_requests is the only thing that changed.  We 
would *tend* to persist it as a consequence to other session updates 
like prealloc_inos, but if one is simply issuing lots of metadata 
updates to existing files in a loop, the sessionmap never gets written 
back (even when expiring log segments).

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?

Cheers,
John

1. https://github.com/ceph/ceph/pull/3718

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

[Greg Farnum]

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@redhat.com> wrote:
> 
> On 04/03/2015 12:14, 严正 wrote:
>> 
>>> 在 2015年3月4日，05:39，John Spray <john.spray@redhat.com> 写道：
>>> 
>>> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html