GEustace@massey.ac.nz (Glen Eustace) (10/03/90)
I am using PC-NFS to mount a remote drive on a Sun 386i. This particular file system is also mounted by several other PCs and hence is mounted with the /MS (MustShare) option. I have been getting errors which until recently I haven't even been able to find the reporter let alone the cause and I hope that some one else may be able to throw some light on the DOS behaviour and consequently the NFS behaviour. Command.com's critical error handler reports the error, Sharing Violation Abort, Fail ? Neither A nor F normally succeed in doing anything, the message is simply repeated and the PC must be rebooted. Today I finally managed to get this error to occur when simply doing a DIR on a directory on the remote drive. I did manage to get back to a prompt and ran NET USE, it reported D: /MS? etc etc. I have never seen the ? after the MS before and assume PC-NFS is considering the sharing to be suspect ? Dismounting and Remounting the drive returns it to the normal /MS status. Can someone tell me what Sharing Violation means, from the DOS perspective. What is being violated ? In the case above no locking was being done that I was aware of. Has anyone else running PC-NFS ever seen this behaviour before and found a remedy or at least an explanation. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Glen Eustace, Software Manager, Computer Centre, Massey University, Palmerston North, New Zealand. EMail: G.Eustace@massey.ac.nz Phone: +64 63 69099 x7440, Fax: +64 63 505 607, Timezone: GMT-12 12 Glen Eustace, Software Manager, Computer Centre, Massey University, Palmerston North, New Zealand. EMail: G.Eustace@massey.ac.nz Phone: +64 63 69099 x7440, Fax: +64 63 505 607, Timezone: GMT-12 12
geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) (10/03/90)
Quoth GEustace@massey.ac.nz (Glen Eustace) (in <1039@massey.ac.nz>): #[A series of questions about sharing failures] When you enable locking and sharing services by mounting a file system with /MS (or the equivalent in NFSCONF), PC-NFS calls the portmapper on the server to obtain the UDP port for the Network Lock Manager (NLM), squirrels this away in the mount table and sets an internal "MS" flag on the drive. The effect of MS is twofold. First (and most obviously) DOS Lock and Unlock (Int21H 5C00H and 5C01H) calls are intercepted and translated into the equivalent RPCs to the NLM. Secondly, all file opens and closes become subject to file sharing verification, as described in the DOS Technical Reference for the Open (Int21H 3DH) call. When a file is opened, an NLM_SHARE call is made to the NLM to check that it is OK to open the file in the requested mode for the requested use. And obviously, when the file is closed an NLM_UNSHARE call is made to tell the NLM that the file is no longer in use. Thus even if you don't think "any locking is going on", every file open and close is causing at least one RPC call to the NLM on the server. So far, so good. What happens when things break down? Unlike the NFS server, the NLM is a regular user level process, and on a busy server it is possible for the process to get swapped out and not respond for an extended period. Obviously this is more likely on a smaller or slower server. There is another potential problem. Suppose the server is rebooted, or even that the NLM is killed and restarted. Any locks/shares that it was holding on behalf of its clients are lost. In Unix there is a mechanism to re-establish locks, based on the status monitor. (For more details, see the Usenix paper by Jo-Mei Chang from ~1986.) Unfortunately this is too heavyweight a scheme to shoehorn into a PC. And even if there were no open files, and thus no outstanding locks or shares to be recovered, the UDP port in the mount table is going to be incorrect after the NLM is restarted for any reason. In PC-NFS 2.0, 3.0 and 3.0.1 any server failure - real or perceived - is treated as fatal to the current application if it touches the affected drive. This is prudent; it is also the way in which most other PC networks handle things. However we also mark the drive as FAILED (which is where the "?" in the "NET USE" display comes from) and disallow any further access to the drive until it has been remounted. Any attempted access will provoke the critical error message you describe. This is actually overkill, and in the next release of PC-NFS we'll fix this and call the portmapper to reacquire the NLM port. This means that if you have a drive mounted /MS and someone reboots the server, the next time you touch a file on the drive PC-NFS will try the old port, time out (which takes a few seconds) and then get the new port and proceed. Geoff -- Geoff Arnold, PC-NFS architect, Sun Microsystems. (geoff@East.Sun.COM) -- *** "Now is no time to speculate or hypothecate, but rather a time *** *** for action, or at least not a time to rule it out, though not *** *** necessarily a time to rule it in, either." - George Bush ***