Date: Fri, 23 Apr 2004 18:10:44 -0400 From: Stephan Uphoff <ups@tree.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Stephan Uphoff <ups@tree.com> Subject: Re: Re99: how to flush out cache.? Message-ID: <200404232210.SAA06432@stups.com> In-Reply-To: Message from Matthew Dillon <dillon@apollo.backplane.com> <200404230326.i3N3QBAp004589@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200404232210.SAA06432>