lkml.org 
[lkml]   [2000]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: The INN/mmap bug


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/

\
 
 \ /
  Last update: 2005-03-22 12:39    [W:0.124 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site