Hi

It was a little tricky to come up with a good subject, but ill explain it better here.

Not long ago we went from a diry hack of having a mounted sshfs area to using the more comfortable solution of using nfs (although unencrypted), since we are dealing with a large amount of space that needs to be used every day we choose nfs which is also the usual protocol people are using to store large amounts of space these days.

There is a backup script that runs backups of some large databases every day and this is working fine when using the sshfs area mounted up against the filesystem on the nfs server, but when we`re using the nfs mounted directory with a nfs filesystem it fails.. in the messages file it says that the nfs server is not responding when it actually is, and we have no problems writing to the directory when the message appears in the log, so this is a kernel bug related to nfs.

i did a system call trace on the backup script and it seems to be hanging for a while on a read call (we still at this point have no problems creating files in the nfs mounted directory) and when i look at the read call i can see which file descriptor number it is trying to read from.. when going into the /proc/PID/fd directory it shows all file descriptors the processes is using at the moment and then i see a symbolic link to the file that it is trying to read from (its actually not a file, its a pipe, but it was easier explaining it that way) ... when i do a "file 12" (the symbolic link has the name "12") i get the following, "broken symbolic link to pipe[:a number]" and i dont understand why. the symbolic link is a link to itself for some reason. when i have a look at other processes they also have some broken symbolic links to pipes or files (these are random processes that i checked that has nothing to do with nfs and they appear to be working flawlessly).

The read system call hangs for about 10 minutes and then it fails.. the output of the system call trace is too large for me to capture with less or more so im unable to see the return result of the read command, i guess i cold redirect the output to a file, although i dont really see how it would help either way to just see that the read function failed or didnt fail because im not able to see what it actually is reading from other than a broken symlink to a pipe (which is linked to itself like explained earlier).

When we are getting the nfs not responding message as said above we have no problem writing to the nfs area, there is nothing hanging or anything.. but when we try the backup script on the sshfs mounted file system (to the same nfs server) the script runs without problems, so the problem seems to be with nfs, but i just cant see how.. and i dont think its related to problems with the nfs server. we dont have access to the nfs server, but could get a request to have it checked, but i doubt it would do any good. we have tried different nfs options like setting up how many bytes that should be allowed transfered to and from the client/server, hard limits and so on.

i also did a tcpdump, the client is communicating with the nfs server periodically, although the not responding part is being written to the log right after the communication ends for some reason which is wierd when we have no problems writing to the nfs area, no i/o errors or anything.. but i really suspect a kernel bug here.

Does anyone know why there is a broken symlink to a pipe in the /proc directory? (this is also the case for other processes for some reason that is unrelated to nfs and seems to work without problems)

Does someone know how we can resolve the problem with the nfs area not working when the backup script is running?