https://bugzilla.novell.com/show_bug.cgi?id=856916 https://bugzilla.novell.com/show_bug.cgi?id=856916#c41 --- Comment #41 from Scott Couston <secure@aphofis.com> 2014-06-15 13:22:40 EST --- (In reply to comment #38)
This long hanging is to be expected and normal. There are only two ways to handle this case of connection loss selected via fstab mount options: hard: wait forever until the server returns soft: give up and return an error to the application
I think, the file-not-found error is because the update was now released so you should get it with zypper up nfs-client
I have taken a very outside look at what we ship by default. We provide NFS Services via via Yast with great ease so the default we ship is the root of our problems. I think its better to ship NFS services as we do but using the default of soft rather than our current wait forever. Here's where your overview of the project's perspective development comes in. Sharing Network drives is fundamental and everyone expects it to just work. Network share's are now mandatory not 'a like to have option' when people buy Enterprise or use Open. Yes I can hear you in the background...but with Enterprise there is most certainly Netware File Services available but until we have a Linux based Netware File Server we'd better get our own house in order. Can we simply ship NFS Services via the API to use the soft option. There must be a disadvantage there somewhere. Asking people to go from NFS Services API and put them in the 'Partitioner' is the most frightening thought I could. imagine. The reason I pushed to kernel based NFS services should not be from the point of just retrying the mount or dismount command via the scheduler. If our kernel based NFS services cant just sit there in perpetuity watching network services appear or disappear from the other PC's that join or shutdown; we need a rethink on how we apply this to the kernel. As we both discussed the loss of a once associated NFS Client Server relationship and you remove its server by downing the PC; simply saving a file is 90 seconds in delay! This is where I have the luxury of saying this is not commercially acceptable so lets toss the idea of managing NFS by the kernel that doesn’t cause any delay. Spending 90 second delay in saving a file is just not happening in a viable alt O/S...We have got to get smart so lets get a few more dynamic idea together as what we are currently doing isn’t happening well! Your serve :-) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.