Ceph » CephFS

I'm not sure this is wrong, but it's confusing me a bit. I thought that the Client sent all capabilities it holds back to the MDS during the reconnect/replay sequence without needing a kick of any kind.
goes and looks
Ah, but it doesn't send back a full Capability struct, so we do in fact need to re-send the cap update. I'd have thought a size change would already be on the re-send list but I guess it's not since it's a request and not a tell (ie, doesn't count as flushing the caps, which is the only list we have), so it has different invariants than the existing list, so this approach looks good to me.

I spent most of this morning figuring out if it made sense to send the full cap (ceph_mds_caps -- and get rid of the cap_reconnect_t). I think the behavior at the mds is too different though, or at least, doing so wouldn't qualify as a 'fix'.

There might be other cap fields that don't get passed along in the cap_reconnect_t (truncate_size, truncate_seq?) that will get dropped till the mds sends a cap update again...

I believe those are okay as truncate size changes should end up actually journaled (as setattrs) so they'll be replayed, and I think the max size change is the only thing that qualifies as a non-dirty "ask" instead of a dirty and flushing "tell" (that's new terminology I just made up).
It's always wise to check and see if there are related fields that have the same bugs as something you just fixed, though, so you should check and see if there are other things happening via the caps that we're missing here.

FYI:
The kclient deals with this case by calling wake_up_session_caps(). It just clear i_wanted_max_size/i_requested_max_size and wakes up the writer.

Oh, yeah, we can do the same in the userspace client. I'll do that and re-push. Thanks Yan!