From - Fri Sep 19 07:20:34 1997 Newsgroups: comp.os.vms Path: news.mitre.org!blanket.mitre.org!agate!howland.erols.net!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!news.new-york.net!news.spc.edu!spcuna.spc.edu!not-for-mail From: Terry Kennedy Subject: Re: SET VOLUME/REBUILD Content-Type: text/plain; charset=US-ASCII X-Newsreader: TIN [UNIX 1.3 unoff BETA release 961018] X-Complaints-To: Email abuse@spc.edu if this posting is inappropriate Content-Transfer-Encoding: 8bit Organization: St. Peter's College, US Lines: 60 Message-ID: References: <009BA18F.739A02F0.3@ccnmr.mit.edu> <34171AE8.1B45@ACM.ORG> <34195726.6339@star.enet.dec.com> <341E6B13.52536ED1@star.zko.dec.youknowwhere> Mime-Version: 1.0 X-Trace: spcuna.spc.edu 874614881 13057 terry [192.107.46.131] X-Nntp-Posting-Host: spcuna.spc.edu Date: Thu, 18 Sep 1997 20:34:41 GMT Andy Goldstein writes: > URRRKK!! Please tell me, where is this interface documented? As far as > we're concerned, the mount and file system locks are internal > mechanisms. Sticking fingers or other appendages in them will cause them > to malfunction. In particular, taking a count of volume locks > outstanding on a volume is precisely how the file system determines > whether it is the last to dismount a volume. So holding another lock on > the volume will definitely interfere with final dismount. Beats me. It was a problem in a prior version of the MultiNet NFS server, and Colorado talked to Ken Adelman about it, and the email I got back said "documented interface". Colorado suggested an alternate method, which TGV previously used but changed because that method caused system crashes on dismounts. Here's a snippet of the message: |> If this could be forwarded to the specialist who handled the original call |> ("Frank" at extension 21143) I would greatly appreciate it. | |> When we last left this call, we had isolated the problem to MultiNet serving |> the disk. A call to Ken Adelman at TGV (makers of MultiNet) reveals that they |> use only documented interfaces and they would like to talk to you about the |> situation so that it can be fixed (either by DEC or by TGV). When that happens, |> *then* we can close the call. | |> If you could contact Ken Adelman of TGV at 408-427-xxxx, or via Internet at |> adelman@tgv.com, I'd really appreciate it. [Otherwise, I'll have to keep open- |> ing critical calls on this until I get you folks together 8-] | | I spoke with someone there this evening, but I didn't have any | paper to write down his name on. Anyways, here is the deal -- | | MOUNT is indeed counting the owners if the volume lock to | determine how many times (nodes) a volume is mounted. If someone else | holds the volume lock (The NFS Server does this) this will screw up | MOUNTs logic and corrupt the mount count field on the disk, resulting | in a subsequent unnecessary rebuild operation. Now that DEC and TGV | understand this problem, we both agree that there is absolutely no | chance of data corruption due to it, and the ONLY problem is the | unnecessary volume rebuild which result. | | DEC's suggestion is to instead of holding the volume lock I use | the lock ID of the system-wide volume lock as the parent of the | sublocks. This technique is valid, and was originally used by our NFS | Server (prior to V2.2). My notes from that change: | | Tue Nov 14 13:45:56 1989 [KZA] Version 1.5(140): | Fixed the NFS Server to hold the parent volume lock itself | rather than make the blocking locks children of the | system-wide lock. This is a workaround for the VMS bug which | crashes the system when you dismount an active disk. | | DEC speculates, and I agree, that there have been a number of fixes to | the lock manager since than, and that we should give it another shot | "the right way" and debug those crashes if we get them. I also suspect | that our new scheme of using the dismount lock makes the situation which | could excite this bug impossible. Terry Kennedy Operations Manager, Academic Computing terry@spcvxa.spc.edu St. Peter's College, Jersey City, NJ USA +1 201 915 9381 (voice) +1 201 435-3662 (FAX)