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
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
