From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 23 15:19:28 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F46716A4CE for ; Fri, 23 Apr 2004 15:19:28 -0700 (PDT) Received: from mxsf05.cluster1.charter.net (mxsf05.cluster1.charter.net [209.225.28.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E5AB43D41 for ; Fri, 23 Apr 2004 15:19:27 -0700 (PDT) (envelope-from ups@tree.com) Received: from stups.com ([209.187.143.11])i3NMAkjH063957; Fri, 23 Apr 2004 18:10:56 -0400 (EDT) Received: from tree.com (localhost [127.0.0.1]) by stups.com (8.9.3/8.9.3) with ESMTP id SAA06432; Fri, 23 Apr 2004 18:10:44 -0400 Message-Id: <200404232210.SAA06432@stups.com> X-Mailer: exmh version 2.0.2 To: Matthew Dillon In-Reply-To: Message from Matthew Dillon <200404230326.i3N3QBAp004589@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Apr 2004 18:10:44 -0400 From: Stephan Uphoff cc: hackers@freebsd.org cc: Julian Elischer cc: Stephan Uphoff Subject: Re: Re99: how to flush out cache.? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2004 22:19:28 -0000 Matthew Dillon wrote: > The idea with the fix is as follows: > > * It's hard to make the VM system invalidate buffers, so don't try. > But it is easy to throw away clean buffers since they are nicely sorted and easy to release. Efficient locking is a bit tricky but should not be to bad. > > Instead, make UFS recognize the IO_INVAL ioflag and mark the buffer > appropriately in the putpages -> generic put pages -> VOP_WRITE() path. This is a nice optimization - so we don't have to delete the buffer once it is clean. > > This only occurs if the msync'd map was writable. If the msync'd map was > only readable, then the data is not flushed through the vnode system and > the pages will not be removed if there happens to be a buffer associated > with them, even if the buffer is clean. I would advise to also flush read only mapped data. (like 5.x) On writeable maps clean pages will also not be removed if a buffer is associated with them. ( For example the sequence msync(a,l,MS_SYNC); msync(a,l,MS_INVALIDATE|MS_SYNC ) will not invalidate/destroy the buffers) > > I think this is reasonable. Not perfect, but reasonable. > > * Set clean_only to TRUE when calling vm_object_page_remove(), which > causes vm_object_page_remove() to ignore wired or dirty pages. This > code is called for both readable and writable maps so we can't just > remove the page unconditionallty, hence clean_only should be > set to TRUE. Yes - see earlier email. > > This means that any pages associated with the buffer cache will NOT > be removed if the map was read-only. If the map was writable, then > the IO_INVAL fix above will destroy the buffer and the page should > wind up not being wired any more, and thus will be properly removed. > > That's it! > > -Matt The patch solves the data loss problem. This is the really critical part. When I get the time (probably not next week) I will write a patch to release the cached buffers that would prevent page removal. Stephan