mismatch_cnt != 0, member content mismatch, but md says the mirror is good

Ben Scott dragonhawk at gmail.com
Thu Nov 19 19:59:56 EST 2009


On Thu, Nov 19, 2009 at 7:13 PM, Michael ODonnell
<michael.odonnell at comcast.net> wrote:
> Yah, you're referring to the case where a page that's just been written
> out is immediately dirtied again so those freshly written disk data are
> abandoned since they're no longer the most recent bits representing
> the page in question.

  Right:

A1. Kernel decides a memory page is LRU and begins to swap it
A2. Swap file block on one mirror member is written
A3. In-memory page is written to (dirtied)

  Once A3 happens, the page is no longer LRU, and thus no longer a
candidate for swapping.  The kernel doesn't have anything to write to
the second mirror member, since the page changed.  And there's no
point in writing that page to both disks just for the sake of keeping
the mirror consistent.  That block's contents will never be read; it's
invalidated swap.  If the system does need that block for swapping
again, it will have to write the new page contents to both mirror
members anyway.

>  He indicates that he thinks this might also
> be possible for memory mapped files but now that I've read it again I
> confess I don't understand his follow-up ...

  Yah.  Swap is special because the kernel can know a block will never
be read again.  For a regular file, it's a lot harder to make that
determination.

  The only things I can think of would be ftruncate(2) and unlink(2).
Maybe there's a lot of dirty blocks (queued writes) in the process of
being written, when the file is truncated or unlinked.  The kernel now
knows those blocks will never be read, so it doesn't worry that it
started writing them but didn't finish.

  But that's just a guess.  It'd be nice to hear from someone who
actually knows what they're talking about.

> ...so I guess the only thing we know for sure is that these guys know the
> problem exists and don't believe it to be dire.

  Morton Thiokol didn't think cold O-rings would be a dire problem,
either... :-/

> FWIW, as in your case the MD device this was
> reported against is not engaged in any swapping.

  Not only that, but for liberty.gnhlug.org, at least, the partition
in question is the boot partition (/boot/).  There's very little on
there -- a couple kernel images, basically.  I wouldn't think the
truncate/unlink scenarios would ever happen to those files.

-- Ben



More information about the gnhlug-discuss mailing list