> >> Removing the first "!lazy &&" resolved my immediate problem. > > Can you explain further what your "immediate problem" was? It was the typical hall of mirrors: 1. upgrade NFS clients Mandriva 2007.1 -> Mandriva 2008.1 2. change in log files on server when client reboots - no "unmount request" messages logged. Otherwise client shutdown seemed normal. 3. tracked that to the /etc/rc.d/init.d/netfs script, which came down to a "umount -f -l", where the behavior of -l had changed between releases. 4. tracked the -l behavior through a change in umount (actually two) such that in the current version the umount.nfs function is entirely dependent on the external program, whereas in the former version it would do it itself if that external program was not found. 5. tracked the -l behavior to the !lazy line in nfsumount.c which was mentioned in the first post in this thread. 6. removing the "!lazy &&" restored the previous logging behavior by the client on shutdown. > To clarify that, "-l" is used in cases where there are still > outstanding NFS RPCs in the kernel for that mount point, but they > can't complete because the server isn't available. Thus the mount > point appears busy, and won't umount. "umount -l" is used here to > prevent the system shutdown from hanging. > > When there may be outstanding NFS requests, the client really > shouldn't send the MNT_UMNT. In general, though, MNT_UMNT is entirely > advisory, and the client shouldn't wait for it to complete. That's what I'm getting at. But rather than trying to send it, and doing so in such a way that it won't lock up if the server is down, it sends nothing. This changes the behavior of a normal shutdown as seen from the server side. > One of the changes I made in my IPv6 patches is to shorten the timeout > on that clnt_call(). We could even go so far as to make MNT_UMNT > entirely asynchronous and not wait for the reply. That sounds good to me. If the client makes a "reasonable effort" to send the "unmount request" to the server, so that under normal working conditions the server will be notified, that should be sufficient. One thing that bothers me though are these two situations: dd if=/dev/zero of=/mountpoint/datafile count=1000000 bs=512 umount -f -l /mountpoint and dd if=/dev/zero of=/mountpoint/datafile count=1000000 bs=512 & umount -f -l /mountpoint What happens to the data being written to datafile, does it make it to the server, assuming the server is up and working normally? The client mounted /mountpoint with bg,hard,intr,rw. Thanks, David Mathog mathog@xxxxxxxxxxx Manager, Sequence Analysis Facility, Biology Division, Caltech -- 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
