linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: joystick <joystick@shiftmail.org>
To: Justin Piszcz <jpiszcz@lucidpixels.com>
Cc: 'joystick' <joystick@shiftmail.org>,
	'linux-raid' <linux-raid@vger.kernel.org>
Subject: Re: 3.12: raid-1 mismatch_cnt question
Date: Mon, 11 Nov 2013 12:06:06 +0100	[thread overview]
Message-ID: <5280BA1E.6060604@shiftmail.org> (raw)
In-Reply-To: <000301cedec0$1fa72d60$5ef58820$@lucidpixels.com>

On 11/11/2013 10:26, Justin Piszcz wrote:
> -----Original Message-----
> .................
>

Very bad news then. Mismatches belong to occupied filesystem space. 
Seems like your data indeed got corrupted somehow and reading from 
different drives probably returns different content for existing files.

Most likely culprits that come to my mind:

1- MD raid1 bug
2- SSD bug (what brand and model?)
3- Loose SATA cable
4- Linux or SSD bug on trim, such as trimming wrong offsets killing live 
data
5- MD does not lock regions during check so returns erroneous mismatches 
for areas being written. This would be harmless but your mismatches 
number seems to high to me for this.

I would suggest to investigate further. One idea is to find which files 
are affected, then reading from both disks independently you should be 
able to determine if all wrong data are on the same SSD (probable loose 
cable or SSD bug if they are different) or evenly distributed (probable 
MD raid1 bug or SSD bug if they are identical).

The easiest, if it works, would be to determine the location of 
mismatches, and then get the filename from there.
Unfortunately I don't think MD tells you the location of mismatches 
directly. Do you want to try the following:
/sys/block/mdX/md/sync{_min,_max} should allow you to narrow the region 
of the next check. Then check, then cat mismatch_cnt.
Narrow progressively so that you identify one block only. Invoke sync 
and check again same region a couple of times so to be sure that it's 
not due to point 5 above. Then try debugfs (in readonly mode can be used 
with fs mounted), there should be an option to get the inode from the 
block number... I hope that block numbers are not offset by MD... I 
think it's icheck and then you might need find -inum to find the filename.

Now it's better to inspect the file to confirm it has indeed different 
content on the two sides...

activate bitmap for raid1, preferably with small chunksize
fail 1 drive so to degrade raid1
drop caches with blockdev --flushbufs on the md device such as /dev/md2, 
on the two underlying partitions such as /dev/sd[ab]2, and maybe even on 
the two disk holding then such as /dev/sd[ab] (I'm not really sure what 
is the minimum needed) ; and also echo 3 > /proc/sys/vm/drop_caches
cp the file to another filesystem
reattach drive, let it resync the differences using the bitmap
fail the other drive
drop all caches again
cp again file to another filesystem
reattach drive and let it resync

diff the two copied files... what do you see?

BTW can your system be taken offline or is it a production system? If it 
can be taken offline you can easily dump md5sums for all files from both 
sides of the RAID, that would be quicker.

Regards
J.


  reply	other threads:[~2013-11-11 11:06 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-04 10:25 3.12: raid-1 mismatch_cnt question Justin Piszcz
2013-11-07 10:54 ` Justin Piszcz
2013-11-12  0:39   ` Brad Campbell
2013-11-12  9:14     ` Justin Piszcz
     [not found] ` <527E8B74.70301@shiftmail.org>
2013-11-09 22:49   ` Justin Piszcz
2013-11-10 12:45     ` joystick
2013-11-11  9:26       ` Justin Piszcz
2013-11-11 11:06         ` joystick [this message]
2013-11-11 18:52           ` Justin Piszcz
2013-11-11 21:23             ` John Stoffel
2013-11-11 21:55               ` NeilBrown
2013-11-12  2:49                 ` John Stoffel
2013-11-11 21:58             ` NeilBrown
2013-11-11 22:18               ` Justin Piszcz
2013-11-12  9:30             ` joystick
2013-11-12 10:29               ` Bernd Schubert
2013-11-13 22:10                 ` Justin Piszcz
2013-11-14  8:44                   ` joystick
2013-11-14 10:43                     ` Justin Piszcz
2013-11-14 16:09                       ` joystick
2013-11-14 17:22                         ` Justin Piszcz
2013-11-15  8:51                           ` joystick

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5280BA1E.6060604@shiftmail.org \
    --to=joystick@shiftmail.org \
    --cc=jpiszcz@lucidpixels.com \
    --cc=linux-raid@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).