On Sun, 17 Sep 2000, Linus Torvalds wrote:
> 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?
Ugh. OK, first of all, patch is _not_ correct. Doesn't zero out the end of
partial block.
<note to myself: no patches before the first cup of coffee>
We know that ->writepage() is called and we know that data doesn't get to
the disk. How can it happen? If we can... Oh, fsck. Linus, we could very
well lose the buffers since the moment when page had been read. See what
happens? We recreate the buffer ring for the page and it's nowhere near
"everything uptodate" state.
So yes, reading the buffers is the problem. I'll fix the zero-out part
of that and send the corrected variant. From my reading of
__block_write_full_page() it looks like we are OK wrt assumptions about
the bh state there, but we may need to check other places where we use
prepare_write().
-
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