From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 23 15:22:10 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 3F1B616A4CE for ; Fri, 23 Apr 2004 15:22:10 -0700 (PDT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBB2443D2D for ; Fri, 23 Apr 2004 15:22:09 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc11) with ESMTP id <2004042322220801100p85jae>; Fri, 23 Apr 2004 22:22:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA10352; Fri, 23 Apr 2004 15:22:07 -0700 (PDT) Date: Fri, 23 Apr 2004 15:22:07 -0700 (PDT) From: Julian Elischer To: Stephan Uphoff In-Reply-To: <200404232210.SAA06432@stups.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@freebsd.org 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:22:10 -0000 with this bug could a user zero out /etc/group or similar? I am not sure what the ramification of the bug is.. On Fri, 23 Apr 2004, Stephan Uphoff wrote: > > 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 > >