> So the reboot was for an upgrade from 2.6.26-rcX to 2.6.38-rc3? I > wonder if a reboot (or just a server restart) without changing kernels > would see the same problem? Whoops, typo. It was from 2.6.36-rcX (I think -rc5, but it's scrolled off the logs), not .26. > We work quite hard to ensure that filehandles returned from older nfsd's > will still be accepted by newer ones. But that doesn't mean there > couldn't failed at that somehow in some case.... I understand that sometimes there's an incompatible server change, but I don't ever remember a Linux-linux nfs mount surviving a server reboot. However, the problem I'm complaining about here is more alarming. With a clean client, attempting to *mount* is failing with -ESTALE. > If you manage to reproduce the problem, /proc/fs/nfs/exports before and > after the reboot would be interesting, and ideally also a network trace > showing traffic before and after the reboot (including the operation > that returned the STALE error). Can do. How much detail do you want in the packet trace? Is -vvv enough, or do you want -X as well? Thank you very much for the response; I'll try to reproduce and capture the problem. -- -Colib -- 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
