Date: Tue, 7 Aug 2001 09:10:04 -0700 (PDT) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/29421: Update a file with mmap will cause mtime/ctime changing repeately Message-ID: <200108071610.f77GA4195109@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: Bruce Evans <bde@zeta.org.au> To: Kachun Lee <kachun@pathlink.com> Cc: <freebsd-gnats-submit@FreeBSD.ORG>, <dillon@FreeBSD.ORG> Subject: Re: kern/29421: Update a file with mmap will cause mtime/ctime changing repeately Date: Wed, 8 Aug 2001 02:03:25 +1000 (EST) On Fri, 3 Aug 2001, Kachun Lee wrote: > >Description: > One of my program that used mtime to detect file changes and updated > an index file using mmap stopped working after 4.2-release. I finally > narrowed it down to that the mmap updates would cause the mtime to > 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?200108071610.f77GA4195109>