From owner-freebsd-bugs Tue Aug 7 9:10:25 2001 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 5B37537B406 for ; Tue, 7 Aug 2001 09:10:04 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.4/8.11.4) id f77GA4195109; Tue, 7 Aug 2001 09:10:04 -0700 (PDT) (envelope-from gnats) Date: Tue, 7 Aug 2001 09:10:04 -0700 (PDT) Message-Id: <200108071610.f77GA4195109@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Bruce Evans Subject: Re: kern/29421: Update a file with mmap will cause mtime/ctime changing repeately Reply-To: Bruce Evans Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR kern/29421; it has been noted by GNATS. From: Bruce Evans To: Kachun Lee Cc: , 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