SMB vs NFS on wireless

[Tyris]

Hi guys,

I've been mounting my mp3 server over samba share, but Im getting lack-luster results doing so:

Unfortunately I sometimes forget to unmount the smb share before disconnecting from network or suspending the Z. This has the unfortunate side effect of leaving a zombie smb connection which thinks it is still mounted to the server when I turn the Z back on. The directory shows up with I/O errors when I do an ls. The mount point refuses to unmount, even with umount -f; the only way I can reclaim my share is to reboot and re-establish it.

I was looking for some kind of file system that could withstand a hard disconnect like suspending the Z, and starting it back up at a later time. I hear the Zaurus kernel has NFS client support and I've read that NFS is "stateless", but I've never used it in such a setting.

Has anyone tried NFS on their Z? and did it withstand disconnects/reconnects more gracefully than SMB?

-T

[Tyris]

Well, I went ahead and added NFS support to my file server, and tried to mount a volume with the Z.

Colossal mistake.

While SMB worked well enough and was able to connect and disconnect without any problem, it stalled the mounted volume when doing suspend/resume. NFS mounts worked well enough, but I couldnt get them to unmount under any circumstances, short of a reboot. While I had an NFS mount open I could not suspend the device, suspend caused the Z to freeze and required a reset to recover. Im not certain why NFS caused the Z to be come unstable, not too sure it can be debugged easily.

In short, use SMB, not NFS.

-T

[ced]

what you can do is edit the /etc/pcmcia/network script to mount/un-mount your SMB share during the start and stop events.

[rgrep]

Well, I went ahead and added NFS support to my file server, and tried to mount a volume with the Z.

Colossal mistake.

While SMB worked well enough and was able to connect and disconnect without any problem, it stalled the mounted volume when doing suspend/resume. NFS mounts worked well enough, but I couldnt get them to unmount under any circumstances, short of a reboot. While I had an NFS mount open I could not suspend the device, suspend caused the Z to freeze and required a reset to recover. Im not certain why NFS caused the Z to be come unstable, not too sure it can be debugged easily.

In short, use SMB, not NFS.

-T

Did you try mounting the NFS using the 'soft' option?  The default is 'hard' which might explain the problems you had.  From nfs(5):

Code: [Select]

soft          If an NFS file operation has a major timeout then report
               an I/O error to the calling program.  The default is  to
               continue retrying NFS file operations indefinitely.

hard          If an NFS file operation has a major timeout then report
               "server not responding"  on  the  console  and  continue
               retrying indefinitely.  This is the default.
To use soft mode, just add -o soft to your mount command-line or include it in the options field of your NFS mount in /etc/fstab.

[Tyris]

Hi guys,

Thanks for the ideas, and help!

Unfortunately I've stripped nfs support from my file server, but will try this again shortly.

For the time being, Im trying the mount/dismount in /etc/wlan/network.
This has had mixed results:

This works like a charm from the command line and from the network icon on the taskbar but shows different behavior on machine suspend/resume. When I suspend it doesnt appear to unmount, and I get a stalled machine when I resume and do an ls in the mounted directory.

Does anyone know what command is called by the suspend? hopefully its not just ifconfig or nothing at all

I'd like to wrap the suspend command in a script and add in the umount to clear my SMB share.
I may try NFS again this weekend.

-T

[mike151]

have you tried the suspend/resume architecture ? You may want mount/umount on those events.

Cheers,
Mike

[Tyris]

have you tried the suspend/resume architecture ? You may want mount/umount on those events.

Havent tried that yet. That looks like its the perfect solution.

This should work with the SL6000 right?

-T