Date: Wed, 8 Dec 1999 22:46:34 +0000 (GMT) From: Richard Wendland <richard@netcraft.com> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: freebsd-hackers@FreeBSD.ORG Subject: mmap() and atime/mtime Message-ID: <199912082246.WAA00863@ns0.netcraft.com> In-Reply-To: <199912081903.LAA40643@apollo.backplane.com> from Matthew Dillon at "Dec 8, 99 11:03:16 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote:
> Things like file meta-data always sync, though if the only data written
> to a file is through such an mmap() the filesystem will not have much
> to do there.
Incidentally, I notice that files "read" through a mmap (PROT_READ,
MAP_SHARED) don't cause the file's atime to be set, on 3.3-STABLE
and 2.2.8-STABLE at least.
This doesn't strike me as the right thing to do, even if the stat(2) man
page says:
st_atime Time when file data last accessed. Changed by the mknod(2),
utimes(2) and read(2) system calls.
From a quick test, it does seem that "writing" through mmap does
cause mtime to be set, despite stat(2) saying:
st_mtime Time when file data last modified. Changed by the mknod(2),
utimes(2) and write(2) system calls.
Good, other incremental backup systems might not work properly.
However I do notice that the modification time isn't set until a
short time after process exit (with an implied munmap & close),
presumably by the syncer.
However we do have the somewhat strange situation that
atime < mtime.
The Open Group Single UNIX Specification Version 2 says in:
http://www.opengroup.org/onlinepubs/007908799/xsh/mmap.html
"The st_atime field of the mapped file may be marked for
update at any time between the mmap() call and the
corresponding munmap() call. The initial read or write
reference to a mapped region will cause the file's st_atime
field to be marked for update if it has not already been
marked for update.
The st_ctime and st_mtime fields of a file that is mapped
with MAP_SHARED and PROT_WRITE, will be marked for update
at some point in the interval between a write reference to
the mapped region and the next call to msync() with MS_ASYNC
or MS_SYNC for that portion of the file by any process. If
there is no such call, these fields may be marked for update
at any time after a write reference if the underlying file
is modified as a result."
So it looks likely the commercial Unix's set atime. From a quick
test it looks like Linux does as well.
Seems to me FreeBSD should do the same.
I'm inclined to the view that it would be nice if mtime was set at
the first write reference that would change the underlying object,
but not synced out to disk at that time. This means running
processes do at least see the mtime change immediately, just as
they'd see the changes if they mmap'd the file.
Richard
--
Richard Wendland richard@starburst.demon.co.uk
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912082246.WAA00863>