On Mon, 7 Feb 2011, Gregory Farnum wrote: > On Mon, Feb 7, 2011 at 5:51 PM, Brian Chrisman <brchrisman@xxxxxxxxx> wrote: > > I was playing around with implementing this. I was trying to get the > > ceph client's export functions to return NFS4ERR_FHEXPIRED instead of > > ESTALE (hoping that my nfs4 clients would then attempt the full lookup > > again). I noticed also that the mds itself can also return an ESTALE > > to the ceph kernel client, which seems to be getting propagated back > > to the NFS client. I'm wondering where I could intercept that and > > send back an expiry notice? > > I don't think you want to: the MDS only returns ESTALE to the client > if it can't find the inode, but that can happen normally if > responsibility for the inode has been moved to another MDS. The client > should be able to handle this circumstance and from a quick check > that's the only way you're going to get ESTALE back from the MDS > (unless something is horribly broken). Normally, yes. If the ceph client keeps the inode in its cache, it should never get an ESTALE it can't mask (I think that'd only happen when a request races with a metadata migration between MDSs). NFS reexport is the one case where that doesn't hold true, because the NFS client can hold onto a file handle for as long as it wants and then present it back to the server. sage
