<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Startled by &#8220;component device mismatches&#8221; on RAID1 volumes</title>
	<atom:link href="http://bergs.biz/blog/2009/03/01/startled-by-component-device-mismatches-on-raid1-volumes/feed/" rel="self" type="application/rss+xml" />
	<link>http://bergs.biz/blog/2009/03/01/startled-by-component-device-mismatches-on-raid1-volumes/</link>
	<description>Just another WordPress weblog</description>
	<lastBuildDate>Sat, 03 Dec 2011 20:21:04 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.5</generator>
	<item>
		<title>By: Alex</title>
		<link>http://bergs.biz/blog/2009/03/01/startled-by-component-device-mismatches-on-raid1-volumes/#comment-56113</link>
		<dc:creator>Alex</dc:creator>
		<pubDate>Mon, 01 Aug 2011 13:21:54 +0000</pubDate>
		<guid isPermaLink="false">http://bergs.biz/blog/?p=68#comment-56113</guid>
		<description>In my case mismatches had exactly the value of 128 and appeared only for /boot partitions on raid1. I think this pretty normal, because event sequence was as follows:
1) OS installed on 2 HDDs with /boot and / partitions on RAID1 via mdadm
2) /dev/sdb at some point became faulty and was replaced
3) sfdisk -d /dev/sda &#124; sfdisk /dev/sdb
4) mdadm /dev/md0 --add /dev/sdb1
5) echo -e &quot;root (hd1,0)\nsetup (hd1)\nquit&quot; &#124; grub --batch

At stage 5) grub writes directly to HDD, omitting the raid1 level, so /dev/sda1 and /dev/sdb1 become out of sync and weekly cron job 99-raid-check complains about mismatches.</description>
		<content:encoded><![CDATA[<p>In my case mismatches had exactly the value of 128 and appeared only for /boot partitions on raid1. I think this pretty normal, because event sequence was as follows:<br />
1) OS installed on 2 HDDs with /boot and / partitions on RAID1 via mdadm<br />
2) /dev/sdb at some point became faulty and was replaced<br />
3) sfdisk -d /dev/sda | sfdisk /dev/sdb<br />
4) mdadm /dev/md0 &#8211;add /dev/sdb1<br />
5) echo -e &#8220;root (hd1,0)\nsetup (hd1)\nquit&#8221; | grub &#8211;batch</p>
<p>At stage 5) grub writes directly to HDD, omitting the raid1 level, so /dev/sda1 and /dev/sdb1 become out of sync and weekly cron job 99-raid-check complains about mismatches.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Administrator</title>
		<link>http://bergs.biz/blog/2009/03/01/startled-by-component-device-mismatches-on-raid1-volumes/#comment-43678</link>
		<dc:creator>Administrator</dc:creator>
		<pubDate>Sun, 13 Mar 2011 13:47:37 +0000</pubDate>
		<guid isPermaLink="false">http://bergs.biz/blog/?p=68#comment-43678</guid>
		<description>It happened that I saw this error (again) a couple of days ago. Since it startled me again I googled for it -- and came across my own above article as the first hit. I had simply forgotten that I had seen and investigated this error already a while ago... :-)</description>
		<content:encoded><![CDATA[<p>It happened that I saw this error (again) a couple of days ago. Since it startled me again I googled for it &#8212; and came across my own above article as the first hit. I had simply forgotten that I had seen and investigated this error already a while ago&#8230; <img src='http://bergs.biz/blog/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Christopher</title>
		<link>http://bergs.biz/blog/2009/03/01/startled-by-component-device-mismatches-on-raid1-volumes/#comment-21754</link>
		<dc:creator>Christopher</dc:creator>
		<pubDate>Sat, 10 Oct 2009 09:42:00 +0000</pubDate>
		<guid isPermaLink="false">http://bergs.biz/blog/?p=68#comment-21754</guid>
		<description>Neil Brown also says, that it is a problem mostly found with Swap on Raid1. Link to the whole discussion is: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518834</description>
		<content:encoded><![CDATA[<p>Neil Brown also says, that it is a problem mostly found with Swap on Raid1. Link to the whole discussion is: <a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518834">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518834</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Administrator</title>
		<link>http://bergs.biz/blog/2009/03/01/startled-by-component-device-mismatches-on-raid1-volumes/#comment-13889</link>
		<dc:creator>Administrator</dc:creator>
		<pubDate>Sun, 01 Mar 2009 09:04:52 +0000</pubDate>
		<guid isPermaLink="false">http://bergs.biz/blog/?p=68#comment-13889</guid>
		<description>&lt;strong&gt;Update:&lt;/strong&gt; I found the following &lt;a href=&quot;http://www.issociate.de/board/goto/1675787/mismatch_cnt_worries.html&quot; rel=&quot;nofollow&quot;&gt;statement from Neil Brown&lt;/a&gt; which seems to be a good explanation why these differences may happen:
&lt;blockquote&gt;Suppose I memory-map a file and often modify the mapped memory. The system will at some point decide to write that block of the file to the device. It will send a request to raid1, which will send one request each to two different devices. They will each DMA the data out of that memory to the controller at different times so they could quite possibly get different data (if I changed the mapped memory between those two DMA request). So the data on the two drives in a mirror can easily be different. If a &#039;check&#039; happens at exactly this time it will notice.

Normally that block will be written out again (as it is still &#039;dirty&#039;) and again and again if necessary as long as I keep writing to the memory. Once I stop writing to the memory (e.g. close the file,
unmount the filesystem) a final write will be made with the same data going to both devices. During this time we will never read that block from the filesystem, so the filesystem will never be able to see any difference between the two devices in a raid1.

So: if you are actively writing to a file while &#039;check&#039; is running on a raid1, it could show up as a difference in mismatch_cnt. But you have to get the timing just right (or wrong).&lt;/blockquote&gt;

</description>
		<content:encoded><![CDATA[<p><strong>Update:</strong> I found the following <a href="http://www.issociate.de/board/goto/1675787/mismatch_cnt_worries.html">statement from Neil Brown</a> which seems to be a good explanation why these differences may happen:</p>
<blockquote><p>Suppose I memory-map a file and often modify the mapped memory. The system will at some point decide to write that block of the file to the device. It will send a request to raid1, which will send one request each to two different devices. They will each DMA the data out of that memory to the controller at different times so they could quite possibly get different data (if I changed the mapped memory between those two DMA request). So the data on the two drives in a mirror can easily be different. If a &#8216;check&#8217; happens at exactly this time it will notice.</p>
<p>Normally that block will be written out again (as it is still &#8216;dirty&#8217;) and again and again if necessary as long as I keep writing to the memory. Once I stop writing to the memory (e.g. close the file,<br />
unmount the filesystem) a final write will be made with the same data going to both devices. During this time we will never read that block from the filesystem, so the filesystem will never be able to see any difference between the two devices in a raid1.</p>
<p>So: if you are actively writing to a file while &#8216;check&#8217; is running on a raid1, it could show up as a difference in mismatch_cnt. But you have to get the timing just right (or wrong).</p></blockquote>
]]></content:encoded>
	</item>
</channel>
</rss>

