From owner-cvs-all Sat Oct 13 9:26:32 2001 Delivered-To: cvs-all@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 8937A37B419; Sat, 13 Oct 2001 09:18:25 -0700 (PDT) Received: (from dillon@localhost) by earth.backplane.com (8.11.6/8.11.2) id f9DGIJ543530; Sat, 13 Oct 2001 09:18:19 -0700 (PDT) (envelope-from dillon) Date: Sat, 13 Oct 2001 09:18:19 -0700 (PDT) From: Matt Dillon Message-Id: <200110131618.f9DGIJ543530@earth.backplane.com> To: Dag-Erling Smorgrav Cc: Mike Silbersack , , Subject: Re: cvs commit: src/sys/vm vnode_pager.c References: <20011012145142.L29945-100000@achilles.silby.com> <200110122026.f9CKQMS35969@earth.backplane.com> <200110130005.f9D05Fb37190@earth.backplane.com> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :Matt Dillon writes: :> Hmm. in re-reading this I think I have to clarify something... :> when I said 'before the dirty buffer is flushed' I meant that if you :> write() a small file and then mmap/access it before the buf_daemon :> gets around to flushing the buffer that was diritied by the write, then :> the mmap/access will put the page into the weird state. The same thing :> can occur if you mmap() a file shared+RW and modify the fragment via :> the mmap. : :Hmm, cvsup doesn't seem to use mmap for I/O. What do you mean by :"access" in this context? : :DES :-- :Dag-Erling Smorgrav - des@ofug.org Any mmap()'d access (read or write) to a recently modified file can trigger the problem. If the file is not mmap()d the problem does not occur because write() only modifies those dirty bits within the range of the file. It's the page fault that causes the dirty bits to be forced to VM_PAGE_BITS_ALL (extending them past the file EOF). If the page in question is backed by a filesystem fragment on the physical disk rather then a filesystem block, the problem can occur. Your particular case may or may not have anything to do with this bug. If you are running cvsup or running a cvsupd or otherwise doing things that scan the file tree, mounting with 'noatime' is the most important thing you need to do. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message