Date: Thu, 24 Sep 1998 10:08:21 -0700 (PDT) From: Matthew Dillon <dillon@backplane.com> To: committers@FreeBSD.ORG Subject: Re: Having some serious file write / mmap inconsistancy problems Message-ID: <199809241708.KAA20887@apollo.backplane.com>
next in thread | raw e-mail | index | archive | help
I've done some more tracing, but it's almost black magic. Can someone
explain this?
* bdwrite() sets B_DELWRI in the bp, but then it goes off and calls
vfs_clean_pages() on the underlying pages.
* There are a number of situations where the pages can be disassociated
from the bp. vm_hold_free_pages() will disassociate the pages,
allocbuf() may disassociate pages, and vfs_vmio_release() will
disassociate the pages. All of these can occur in situations where
B_DELWRI is completely ignored.
* Once the pages are disassociated, and since they are marked clean,
the VM system may reuse the pages prior to the B_DELWRI getting out.
If the delayed write occurs and the pages have not yet been reused
by the VM system, they will be reassociated and written out properly.
But if the pages are reused prior to the delayed write occuring it
seems to me that it is possible for the pages to be 'lost'.
Ideas? If I understand it properly we either have to not mark the pages
clean in bdwrite(), or we have to make sure that the pages cannot be
disassociated from the bp while B_DELWRI is set in the bp. Personally,
I think its bad form to mark pages as clean when they are not clean and
that that portion of the code should be reworked to solve whatever problem
marking them clean was supposed to solve. It seems very very odd to me.
-Matt
Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet
Communications & God knows what else.
<dillon@backplane.com> (Please include original email in any response)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809241708.KAA20887>