On Monday June 16, trond.myklebust@xxxxxxxxxx wrote: > On Mon, 2008-06-16 at 11:09 -0400, Chuck Lever wrote: > > > I think an error reply is much better than no reply in nearly every > > case. NFS3ERR_JUKEBOX/NFS4ERR_DELAY is an interesting idea, but > > something else again will probably be required for v4.1 with sessions. > > NFS3ERR_JUKEBOX/NFS4ERR_DELAY may be inappropriate if the nfs daemon has > already started handling the RPC call, since you may be interrupting a > non-idempotent operation. If the filesystem allows you to interrupt a non-idempotent operation part way through, then the filesystem is doing something very wrong. The observed behaviour is that multiple 32K writes are outstanding (in different nfsd threads) when a signal is delivered to each nfsd. OCFS2 appears to be serialising these writes. One of the writes completes returning a length that is less than 32K. This length is returned to the client. A quick look at the client code suggests that it complains with a printk, and tries to write the remainder, which seems correct. The other writes all complete with ERESTARTSYS. Presumably they haven't started at all. If they had, you might expect a partial return from them too. So far, what OCFS2 is doing seems credible and doesn't leave us in an awkward position with respect to incomplete idempotent operations. I cannot be certain, but I'm willing to believe that OCFS2 only returns ERESTARTSYS when the operation hasn't been performed at all (or has been wound-back to the starting condition). I agree that NFS3ERR_JUKEBOX is more appropriate than no reply, but I don't think there is any reason to suspect that will not be sufficient. Thanks, NeilBrown -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
