You are not logged in.
Pages: 1
My SliTaz NFS client hangs on a SliTaz 4.0 system (hd install and live instances). The particulars: portmap IS installed and running on SliTaz, the host/directory is being served via unfs3 (user-space nfs version 3) from my NAS server, the host/directory is successfully mounted on the client with option nolock (a restriction of unfs3). I can cd into the mounted filesystem. I can "ls" directories on the mounted filesystem. I can copy small files (1-4K) to/from the mounted filesystem. BUT if I copy a large file from the mount to a local directory, the copy begins and freezes at 16384 bytes transferred (16K). And after 20 minutes, the amount remains at 16K. The copy hangs until I SIGINT (^C), and any subsequent access to the mount (ls, cd) also hangs.
I can replicate the problem in the older SliTaz 3.0 release. I cannot replicate under Crunchbang (Debian Squeeze) and Tinycore (distant Slack relative) - they mount and copy just fine. Plus the unfs3 server has been running for two years serving nfs shares to *buntu, Debian, Clonezilla, Parted Magic, and Openwrt versions of linux with no problems. So the problem seems specific to SliTaz.
I also have another NFS server that runs from kernel space (also version 3), and I can mount it (with locks) on SliTaz and transfer large files with no problems. So the problem also appears to be specific to unfs3 or the nolock option.
All equipment (server, router, computer) has been restarted/reset and retested.
It has stalled suspiciously on a block boundary, but I cannot figure out why. Any assistance would be appreciated.
Offline
unfs3 has always had weird handling with Busybox, mostly because it has no support for it by default in busybox's mount command. You could try using the real mount command, but it may require the use of the right library to work.
Also FYI, TinyCore has nothing to do with Slackware and it's made from scratch like SliTaz.
Offline
Thanks for your comments about the wonkiness of busybox and the suggestion to try a real mount command. I found mount.nfs in the nfs-utils package and started the required rpc.statd daemon. Specifying nolock (-o nolock) as the only option, it failed with:
mount.nfs: an incorrect option was specified
After some head scratching, I thought maybe one of the default parameters was wrong. So I fed it combinations of what I thought were correct explicit options. The verbose trace (-v) showed it was attempting connections, but I could not decipher the cause of my failure.
Frustrated, I went back to the busybox version and applied explicit options there. My first attempt (-o vers=3,tcp,ro,nolock) worked! I changed to read/write and things are now copacetic.
After more experimentation, I have reduced the solution: the nfs options must include the tcp protocol as well as nolock (-o tcp,nolock) to connect to unfs3 (v 0.9.22). (And there must be a portmap daemon running.) I never did get mount.nfs to work with any set of options.
Thx for the clarification on TinyCore.
Offline
Pages: 1
[ Generated in 0.016 seconds, 7 queries executed - Memory usage: 1.53 MiB (Peak: 1.77 MiB) ]