On 04/13/2012 05:42 PM, Jeff Layton wrote: > (note: please don't trim the CC list!) > > Indefinitely does make some sense (as Peter articulated in his original > set). It's possible you could race several times in a row, or a server > misconfiguration or something has happened and you have a transient > error that will eventually recover. His assertion was that any limit on > the number of retries is by definition wrong. For NFS, a fatal signal > ought to interrupt things as well, so retrying indefinitely has some > appeal there. > > OTOH, we do have to contend with filesystems that might return ESTALE > persistently for other reasons and that might not respond to signals. > Miklos pointed out that some FUSE fs' do this in his review of Peter's > set. > > As a purely defensive coding measure, limiting the number of retries to > something finite makes sense. If we're going to do that though, I'd > probably recommend that we set the number of retries be something > higher just so that this is more resilient in the face of multiple > races. Those other fs' might "spin" a bit in that case but it is an > error condition and IMO resiliency trumps performance -- at least in this case. I am definitely voting against an infinite number of retries. I'm working on FhGFS, which supports distributed meta data servers. So when a file is moved around between directories, its file handle, which contains the meta-data target id might become invalid. As NFSv3 is stateless we cannot inform the client about that and must return ESTALE then. NFSv4 is better, but I'm not sure how well invalidating a file handle works. So retrying once on ESTALE might be a good idea, but retrying forever is not. Also, what about asymmetric HA servers? I believe to remember that also resulted in ESTALE. So for example server1 exports /home and /scratch, but on failure server2 can only take over /home and denies access to /scratch. Thanks, Bernd -- 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
