0

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?

4
  • 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, 2012 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, 2012 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, 2012 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, 2012 at 12:05

1 Answer 1

0

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .