From owner-freebsd-bugs Tue Aug 7 9:50:14 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 8806C37B427 for ; Tue, 7 Aug 2001 09:50:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.4/8.11.4) id f77Go2401307; Tue, 7 Aug 2001 09:50:02 -0700 (PDT) (envelope-from gnats) Date: Tue, 7 Aug 2001 09:50:02 -0700 (PDT) Message-Id: <200108071650.f77Go2401307@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Matt Dillon Subject: Re: kern/29421: Update a file with mmap will cause mtime/ctime changing repeately Reply-To: Matt Dillon 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: Matt Dillon To: Bruce Evans Cc: Kachun Lee , Subject: Re: kern/29421: Update a file with mmap will cause mtime/ctime changing repeately Date: Tue, 7 Aug 2001 09:46:55 -0700 (PDT) :... :> 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 Hmm. Didn't this come up about a year ago? I'll have to look in the archives. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message