On Sun, 17 Sep 2000, Alexander Viro wrote:
>
> It _is_ a bug, unfortunately. Look: he had taken a copy when the thing was
> running. I.e. took the copy of in-core page. After that he stopped innd
> and that had triggered block_write_full_page(). So far, so good, right?
> Except that the page contents didn't reach the disk.
Hmm.. Ok, I see what you're saying. And I looked at the diff the wrong way
around - we _lost_ two articles rather than getting two new ones.
However, what's wrong with the block_write_full_page() logic? Your patch
looks fine to me, but so does the old logic, I have to admit.
Sure, __block_prepare_write() does the "optimize away reads" stuff, but
this all can only happen for pages that are up-to-date, so that shouldn't
matter. __block_commit_write() will certainly mark the buffers dirty, so I
don't see how the data would get lost anywhere.
I bet your patch fixes the corruption, but I want to understand _why_.
Call me dense, but __block_commit_write() seems to do everything we want
done..
I wonder if we have some cache aliasing problem somewhere. Or what's the
bug I overlooked?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:16 EST