Ceph » CephFS

The right fix is probably to just remove that assertion. I don't think it's really valid anyway. cephfs turns the inode into a path when sending it to the MDS. There is nothing that prevents that path changing once the call is in flight.

Actually this is wrong (as Zheng pointed out). The call is made with a zero-length path that starts from the inode on which the setattr is being done. I wonder if we did end up with a similar race though, and got a traceless reply, that could potentially cause this since we do a pathwalk on the client in that case and it could have landed in a different spot than we expected.

this shouldn't happen even for traceless reply. I suspect the 'in' passed to ceph_ll_setattr isn't belong to the 'cmount'

Huh. That is an interesting theory. I don't see how ganesha would do that, but maybe. Unfortunately, the original problem reporter has gone unresponsive, so we don't have a lot to go on here.

Either way, I think the right solution here is to probably to add some more logging (and maybe assertions) to catch these sorts of cases. Maybe with that we'll get a better handle on this problem.