Once again the list comes through. I suspect what we have here is a bug. Kevin
Sheehan, who supplied the key reply leading to the solution, seems to concur.
I will be contacting SUN to see if this is in fact the case.
Thanks to all who took the time to reply.
kalli!kevin@fourx.Aus.Sun.COM (Kevin Sheehan {Consulting Poster Child})
stern@sunne.East.Sun.COM (Hal Stern - NE Area Systems Engineer)
bwalker@auratek.com ( brad w. )
Terry Rosenbaum <tlr@toy.rad.msu.edu>
hoh-2.att.com!whb (Win Bent)
dworkin@merlin.rootgroup.com
"God gives burdens; also shoulders"
Jimmy Carter cited this Jewish saying in his concession speech
at the end of the 1980 election. At least he said it was a Jewish
saying; I can't find it anywhere. I'm sure he's telling the truth
though; why would he lie about a thing like that?
-- Arthur Naiman, "Every Goy's Guide to Yiddish"
---------------------- Original Query ----------------------------
> I was wondering if anyone might be aware of problems using mmap on
> data which resides on an NFS mounted disk.
> One of our programmers is experiencing some really strange problems. The
> mmap function call will work the first time the program is run, however
> the second time the call fails. The data being accessed is nfs
> mounted from a machine, other than the one that the program is being run
> on. Manifestations of the problem is a hung process or system crash,
> neither of which is very nice.
------------------------------------------------------------------
The answer came from:
kalli!kevin@fourx.Aus.Sun.COM (Kevin Sheehan {Consulting Poster Child})
> ....you can't lock *and* mmap() NFS mounted files. If you forget to
> release the lock the system won't let you mmap() it again.
> This is because the system wants to cache the page for mmap(), but locking
> it says you want consistency - so the system doesnt let you cache it.
This pointed us in the right direction. The only problem is that, the locks are
explicitly and correctly released and the file is closed, before another mmap
call is issued.
Clearly things are a little inconsistent (buggy) here: either invalidate a
mapping if a lock is performed on the file after the mapping has been made, or
allow mapping then a lock if a previous lock was properly released. This
possibly points to a further bug in remote locking: when a lock is released,
remote or local, it ** SHOULD BE _GONE_ THEN AND THERE **, not hang around
somehow to invalidate later activities.
It does disappear eventually: for instance, the program can be run on a remote
file and have it work now ( the first time, anyway ). This is after it was
failing to work few hours ago. In the meantime, all that has been done is to
log out and back in, and not much else.
Deleting the files you were locking and mapping also gives a fresh start.
Pain in the butt. It would seem that if you can lock and mmap files
locally, you should be able to do it remotely as well.
Am I missing something here, a patch, something elementary perhaps ? An FM or
any other hint would be appreciated.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:46 CDT