From owner-freebsd-bugs Tue Aug 7 17:20: 7 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 E3F1737B401 for ; Tue, 7 Aug 2001 17:20:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.4/8.11.4) id f780K1T00306; Tue, 7 Aug 2001 17:20:01 -0700 (PDT) (envelope-from gnats) Date: Tue, 7 Aug 2001 17:20:01 -0700 (PDT) Message-Id: <200108080020.f780K1T00306@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 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