Date: Tue, 7 Aug 2001 17:20:01 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/29421: Update a file with mmap will cause mtime/ctime changing repeately Message-ID: <200108080020.f780K1T00306@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/29421; it has been noted by GNATS.
From: Matt Dillon <dillon@earth.backplane.com>
To: Bruce Evans <bde@zeta.org.au>
Cc: Kachun Lee <kachun@pathlink.com>,
<freebsd-gnats-submit@FreeBSD.ORG>
Subject: Re: kern/29421: Update a file with mmap will cause mtime/ctime
changing repeately
Date: Tue, 7 Aug 2001 17:11:21 -0700 (PDT)
Ok, I looked at this some more. It's a bit of a sticky issue
because the buffers in the buffer cache are in fact allowed to
be page-misaligned and so the cleaning *must* be piecemeal, and the
VM fault / VMIO backing code requires the valid/dirty bits to be all
or nothing to avoid forcing a re-read. So when the dirty bits get set,
they *all* have to get set.
But, that said, I think we may be able to use the vnode size
to special-case the cleaning code and to truncate the dirty bits
that occur beyond file EOF. I can't promise when I'll have time to
play with it... hopefully in the next few days.
-Matt
:..
:> change continously (not delay) even after the file was closed,
:> unmmap'ed and had no more writing to it.
:>
:> I used a small program to create a 16 byte file, mmap it, change few
:> bytes, close and unmmap the file. Then I used a perl script to poll
:> the mtime every minute. I tried this on over 12 of our FreeBSD servers.
:> All the stable after 4.2-release would exhibit this problem.
:> The 1 4.1.1-stable and 3 4.2-release servers did not have the problem.
:> ...
:> The time between changes could be a few minutes to a few hours (!).
:> That seems depended on how busy the system was. I built an idle system
:> and ran the test on it a few days ago. The mtime/ctime of the test
:> file on that system has not been changed (yet?).
:
:To duplicate (at least under -current), run something that creates a lot
:of dirty pages. I used lat_fs from lmbench2.
:
:The bug is caused by dirty pages never becoming clean if they are for
:a small mmapped file like the one in your program. The vm system keeps
:setting m->dirty to VM_PAGE_BITS_ALL (0xff), but for small files,
:flushing the pages only results in the lower bits being cleared. E.g.,
:if the fs block size is 1K, then your 16-byte test file takes 2 512-byte
:subpages, and m->dirty gets "cleared" to 0xfc. When the page cleaner
:looks at such pages, it always finds them completely dirty and flushes
:them. Such pages don't go away until their object is destroyed. Their
:object is associated with the vnode for the file so it doesn't go away
:until the vnode is recycled.
:
:Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200108080020.f780K1T00306>