Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have a small home network running, with a NAS box (ICY BOX IB-NAS5220) exporting /home for my various Linux Mint machines.

/etc/exports on the NAS:

/mnt/md1/public      *.fritz.box(rw,sync,no_root_squash)

The relevant line of /etc/fstab on the clients:

192.168.178.3:/mnt/md1/public /home nfs nolock,nfsvers=3 0 0

(nolock is necessary to get Firefox to cooperate. nfsvers=3 is a limitation of the NAS. Paths and IPs are tripple-checked OK.)

This works.

However, I experience rather frequent freezing-up of the clients, especially when surfing the web (firefox) after startup / logging in. The application freezes up for about 10-20 seconds, then everything returns to normal.

Apparently this gets better some time after starting to work, but it is annoying as hell (and keeping me from continuing to set up the remaining machines like this, as it would be a show-stopper for my wife and kids).

Note that this happens even if only one machine is accessing the /home/ directory, so it isn't about concurrent access going wrong. (Although there is a media server mounting the same share, but that one is idle 99% of the time.)

I don't really know enough about NFS and the things going on behind the scenes to know what to look for, and where. Can anyone give me a hint? Is this due to bad NFS server performance? A caching issue? How can I find out? Can this be mitigated by setting certain NFS options?

share|improve this question
    
Note: I know about the implications of no_root_squash. I might remove the need for it at some later time. This isn't about security. –  DevSolar Oct 30 '12 at 6:39
    
You debug a problem like this by first whittling it down to a reproducible case with as few moving parts as possible. A Web browser is too complex; its behavior depends on the site you're visiting, number of tabs open, whether garbage collection is happening, and a few hundred user configurable options. If you were trying to cp a file from the NAS and it took 10-20 seconds to start copying, then that would be a much stronger place from which to start debugging. If you're sure it is the NAS, check it for energy saving sleep modes. It takes time to spin up a bunch of drives. –  Kyle Jones Oct 30 '12 at 7:22
    
@KyleJones: I tried many different approaches, but was unable to reliably reproduce this issue with a given set of instructions. Sometimes access freezes up for several seconds, the next time it's next to instantaneous, then it freezes up again. I tried async and no_wdelay on the NFS server, to no avail. I have no idea how to approach this. –  DevSolar Nov 19 '12 at 11:55
    
@KyleJones: Still no success at reliably reproducing the symptoms. But by now I can say that it even freezes user input at the console (i.e., system doesn't react to keyboard strokes), which makes me suspect a kernel issue. And no, it's not energy savings mode - it doesn't only happen at the first few accesses, but intermittently. I scrapped the "shared home" setup, and hope it gets better when the mount is only a subdirectory of $HOME. –  DevSolar Nov 22 '12 at 12:05

1 Answer 1

up vote 0 down vote accepted

Found the solution in a German FAQ on the similar IB-NAS4220...

Apparently, client and box negotiate a block size of 32 kB... on which the NAS, strangely enough, chokes. (Even much larger blocks usually don't pose a problem with NFS.)

Setting smaller read block sizes in the mount options (rsize=8192,wsize=32768) seems to remove the problem.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.