Simon Stevenson wrote: > We have a recurring problem losing our sharity mounts. > > Running Sharity 2.6 on a solaris E250 running solaris 2.7. > > we mount a windows 2000 filesystem and all goes well and then suddenly the > mount hangs, > if we try to df the fs we get a timeout followed by: > > NFS fsstat failed for server localhost: error 5 (RPC: Timed out) > df: cannot statvfs /mnt/mirror: Connection timed out > > We can't do a cifsumount, we get a device busy > and any attempt to logout a user with that device mounted results in a hang. > > The only solution we have found to this is to reboot our server. This is > becoming untenable and if we can't at least find a fix for this problem we > will have to stop using sharity. > > Does anyone have any similiar experiences and/or know of a less drastic way > to recover from this.
We have heard about a similar problem with large files (over 2GB) and the new NFS3 frontend on Solaris. The message "RPC: Timed out" indicates a serious protocol violation on the connection to the kernel. Sharity does not answer a request as it should. There are several possibilities how this can happen: 1. Sharity has crashed. See the 'ps' listing whether the 'sharityd' process is still running and not hanging uninterruptably. If it has crashed, it should have dumped core. 2. Sharity may still be running, but unable to answer NFS requests for whatever reason. One possible reason is that it deadlocked. You can check this with e.g. 'cifslist -v' or similar commands. If the command hangs, Sharity has deadlocked. If not, it's still servicing requests. 3. The NFS requests do not arrive in Sharity. That would be the kernel's fault. You can check this by enabling the logLevel "nfsTrace" for a short time in sharity.cfg. Sharity re-scans the sharity.cfg file automatically when it has been changed within 5 seconds. If this logLevel is enabled, Sharity logs all NFS requests (and the corresponding replies) to the syslog (facility daemon.error). 4. Sharity's replies do not arrive at the kernel. Again, use the logLevel nfsTrace to check whether Sharity is sending replies. If it does not, Sharity may have deadlocked internally. If it is sending the replies but the kernel does not receive them, it must be a kernel problem. Regards, Christian. -- Dipl.-Ing. Christian Starkjohann Objective Development mailto:[EMAIL PROTECTED] | http://www.obdev.at/ _______________________________________________ Sharity-talk mailing list [EMAIL PROTECTED] To unsubscribe see http://at.obdev.at/mailman/listinfo/sharity-talk
