Linux RAID subsystem development
 help / color / mirror / Atom feed
From: Chris Pearson <pearson.christopher.j@gmail.com>
To: NeilBrown <neilb@suse.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: dirty chunks on bitmap not clearing (RAID1)
Date: Wed, 31 Aug 2011 13:23:01 -0500 (CDT)	[thread overview]
Message-ID: <alpine.DEB.2.00.1108311313550.27546@ubuntu> (raw)
In-Reply-To: <20110831173842.44ab5b03@notabene.brown>

I'm happy to apply a patch to whichever kernel you like, but the blocks have since cleared, so I will try and reproduce it first.

On Wed, 31 Aug 2011, NeilBrown wrote:

>Date: Wed, 31 Aug 2011 17:38:42 +1000
>From: NeilBrown <neilb@suse.de>
>To: Chris Pearson <kermit4@gmail.com>
>Cc: linux-raid@vger.kernel.org
>Subject: Re: dirty chunks on bitmap not clearing (RAID1)
>
>On Mon, 29 Aug 2011 11:30:56 -0500 Chris Pearson <kermit4@gmail.com> wrote:
>
>> I have the same problem.  3 chunks are always dirty.
>> 
>> I'm using 2.6.38-8-generic and mdadm - v3.1.4 - 31st August 2010
>> 
>> If that's not normal, then maybe what I've done differently is that I
>> created the array, raid 1, with one live and one missing disk, then
>> added the second one later after writing a lot of data.
>> 
>> Also, though probably not the cause, I continued writing data while it
>> was syncing, and a couple times during the syncing, both drives
>> stopped responding and I had to power off.
>> 
>> # cat /proc/mdstat
>> Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5]
>> [raid4] [raid10]
>> md127 : active raid1 sdd1[0] sdc1[2]
>>       1904568184 blocks super 1.2 [2/2] [UU]
>>       bitmap: 3/15 pages [12KB], 65536KB chunk
>> 
>> unused devices: <none>
>> 
>> # mdadm -X /dev/sd[dc]1
>>         Filename : /dev/sdc1
>>            Magic : 6d746962
>>          Version : 4
>>             UUID : 43761dc5:4383cf0f:41ef2dab:43e6d74e
>>           Events : 40013
>>   Events Cleared : 40013
>>            State : OK
>>        Chunksize : 64 MB
>>           Daemon : 5s flush period
>>       Write Mode : Allow write behind, max 256
>>        Sync Size : 1904568184 (1816.34 GiB 1950.28 GB)
>>           Bitmap : 29062 bits (chunks), 3 dirty (0.0%)
>>         Filename : /dev/sdd1
>>            Magic : 6d746962
>>          Version : 4
>>             UUID : 43761dc5:4383cf0f:41ef2dab:43e6d74e
>>           Events : 40013
>>   Events Cleared : 40013
>>            State : OK
>>        Chunksize : 64 MB
>>           Daemon : 5s flush period
>>       Write Mode : Allow write behind, max 256
>>        Sync Size : 1904568184 (1816.34 GiB 1950.28 GB)
>>           Bitmap : 29062 bits (chunks), 3 dirty (0.0%)
>
>I cannot see how this would be happening.  If any bits are set, then they
>will be cleared after 5 seconds, and then 5 seconds later the block holding
>the bits will be written out so that they will appear on disk to be cleared.
>
>I assume that if you write to the array, the 'dirty' count increases, but
>always goes back to three?
>
>And if you stop the array and start it again, the '3' stays there?
>
>If I sent you a patch to add some tracing information would you be able to
>compile a new kernel with that patch applied and see what it says?
>
>Thanks,
>
>NeilBrown
>
>
>> 
>> 
>> Quoting NeilBrown <neilb@suse.de>:
>> 
>> > On Thu, October 15, 2009 9:39 am, aristizb@ualberta.ca wrote:
>> >> Hello,
>> >>
>> >> I have a RAID1 with 2 LVM disks and I am running into a strange
>> >> situation where having the 2 disks connected to the array the bitmap
>> >> never clears the dirty chunks.
>> >
>> > That shouldn't happen...
>> > What versions of mdadm and the Linux kernel are you using?
>> >
>> > NeilBrown
>> >
>> >>
>> >> I am assuming also that when a RAID1 is in write-through mode, the
>> >> bitmap  indicates that all the data has made it to all the disks if
>> >> there are no dirty chunks using mdadm --examine-bitmap.
>> >>
>> >> The output of cat /proc/mdstat is:
>> >>
>> >> md2060 : active raid1 dm-5[1] dm-6[0]
>> >>        2252736 blocks [2/2] [UU]
>> >>        bitmap: 1/275 pages [12KB], 4KB chunk, file: /tmp/md2060bm
>> >>
>> >>
>> >> The output of mdadm --examine-bitmap /tmp/md2060bm is:
>> >>
>> >> Filename : md2060bm
>> >>             Magic : 6d746962
>> >>           Version : 4
>> >>              UUID : ad5fb74c:bb1c654a:087b2595:8a5d04a9
>> >>            Events : 12
>> >>    Events Cleared : 12
>> >>             State : OK
>> >>         Chunksize : 4 KB
>> >>            Daemon : 5s flush period
>> >>        Write Mode : Normal
>> >>         Sync Size : 2252736 (2.15 GiB 2.31 GB)
>> >>            Bitmap : 563184 bits (chunks), 3 dirty (0.0%)
>> >>
>> >>
>> >> Having the array under no IO, I waited 30 minutes but the dirty data
>> >> never gets clear from the bitmap, so I presume  the disks are not in
>> >> sync; but after I ran a block by block comparison of the two devices I
>> >> found that they are equal.
>> >>
>> >> The superblocks and the external bitmap tell me that all the events
>> >> are cleared, so I am confused on why the bitmap never goes to 0 dirty
>> >> chunks.
>> >>
>> >> How can I tell if the disks are in sync?
>> >>
>> >>
>> >> Thank you in advance for any help
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>

  reply	other threads:[~2011-08-31 18:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-29 16:30 dirty chunks on bitmap not clearing (RAID1) Chris Pearson
2011-08-31  7:38 ` NeilBrown
2011-08-31 18:23   ` Chris Pearson [this message]
2011-12-22 22:48     ` NeilBrown
2011-12-26 18:07       ` Alexander Lyakas
2012-01-02 22:58         ` NeilBrown
  -- strict thread matches above, loose matches on Subject: below --
2009-10-14 22:39 aristizb
2009-10-15  1:36 ` NeilBrown
2009-10-15 15:15   ` aristizb

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=alpine.DEB.2.00.1108311313550.27546@ubuntu \
    --to=pearson.christopher.j@gmail.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    /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