Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!usc!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!EU.net!sun4nl!eur.nl!cs.few.eur.nl!pk
From: pk@cs.few.eur.nl (Paul Kranenburg)
Subject: Re: mmap(2) semantics
Message-ID: <1993Nov22.235400.1585@cs.few.eur.nl>
Sender: news@cs.few.eur.nl
Reply-To: pk@cs.few.eur.nl
Organization: Erasmus University Rotterdam
References: <SPACE.93Nov21100643@ncc1701.stgt.sub.org>
Date: Mon, 22 Nov 1993 23:54:00 GMT
Lines: 37
In <SPACE.93Nov21100643@ncc1701.stgt.sub.org> space@ncc1701.stgt.sub.org (Lars Soltau) writes:
>What are the exact semantics of the mmap(2) system call?
>To elaborate, I'm having the following problem:
>In BSD/386, any changes you make to the mapped memory do not reflect on
>the actual disk file until you call msync(2), even if you set the
>MAP_SHARED flag on mapping the file. The inn sources do not seem to
>expect this behaviour, either in the dbz code or in the code handling
>the active file. I had to add msync(2) calls in strategic locations so
>that changes would actually reflect on the disk file.
>Is this behaviour correct? Is there a definition on what the correct
>behaviour would be?
For this to answered in a sensible way, we need to distinguish the case where
the modifications are actually reflected by the magnetic particles on your
hard disk (which would be the result of the msync() call) and the case where
another process opens the same file and does a read(2) on it.
Pages mapped to a file with MAP_SHARED on should not be written back to
disk as soon as they get modified. In general, system performance would
degrade seriously if this were done.
On the other hand, one would expect a {open(); read();} sequence to be aware
of the modifications done to that file's mapped pages. If BSD/386 is still
anywhere near the NET/2 code it is derived from, the reason that this is not
the case must be looked for in the almost completely separate views that
the VM subsystem and the (traditional) buffer cache hold of files.
Only when VM map to a file is dismantled (on process exit or by munmap(2))
or when the pager steps in to reclaim physical pages or when doing an explicit
msync(2) will the (contents of the) page be handed back to the vnode layer,
which sees to it that ordinary read()'s have access to it (most likely the
data will linger in the buffer cache for a while).
-pk