From: NeilBrown <neilb@suse.de>
To: Xavier Brochard <xavier@alternatif.org>
Cc: linux-raid@vger.kernel.org
Subject: Re: disk order problem in a raid 10 array
Date: Sat, 19 Mar 2011 12:42:47 +1100 [thread overview]
Message-ID: <20110319124247.41bac36a@notabene.brown> (raw)
In-Reply-To: <201103190059.08093.xavier@alternatif.org>
On Sat, 19 Mar 2011 00:59:07 +0100 Xavier Brochard <xavier@alternatif.org>
wrote:
> Le samedi 19 mars 2011 00:20:39 NeilBrown, vous avez écrit :
> > On Fri, 18 Mar 2011 23:50:18 +0100 Xavier Brochard <xavier@alternatif.org>
> > > Le vendredi 18 mars 2011 23:22:51, NeilBrown écrivait :
> > > > On Fri, 18 Mar 2011 21:12:49 +0100 Xavier Brochard
> > > > > Le vendredi 18 mars 2011 18:22:34 hansbkk@gmail.com, vous avez écrit :
> > > > > > On Fri, Mar 18, 2011 at 9:49 PM, Xavier Brochard
> > > > > > <xavier@alternatif.org>
> > > > >
> > > > > wrote:
> > > > > > > disk order is mixed between each boot - even with live-cd.
> > > > > > > is that normal?
> > > > > >
> > > > > > If nothing is changing and the order is swapping really every boot,
> > > > > > then IMO that is odd.
> > > > >
> > > > > nothing has changed, except kernel minor version
> > > >
> > > > Yet you don't tell us what the kernel minor version changed from or to.
> > >
> > > Previously it was ubuntu 2.6.32-27-server or 2.6.32-28-server and now it
> > > is ubuntu 2.6.32-29.58-server 2.6.32.28+drm33.13
> > >
> > > > That may not be important, but it might and you obviously don't know
> > > > which. It is always better to give too much information rather than
> > > > not enough.
>
> > >
> > > Here's full output of mdadm --examine /dev/sd[cdefg]1
> > > As you can see, disks sdc, sdd and sde claims to be different, is it a
> > > problem?
> >
> > Where all of these outputs collected at the same time?
>
> yes
>
> > They seem
> > inconsistent.
>
> > In particular, sdc1 has a higher 'events' number than the others (154 vs
> > 102) yet an earlier Update Time. It also thinks that the array is
> > completely failed.
>
> When I removed that disk (sdc is number 2) and another one (I tried with
> different disks), all other disks display (with mdadm -E):
> 0 Active
> 1 Active
> 2 Active
> 3 Active
> 4 Spare
>
> But when I removed that disk (#2) and #0, it start to recover and all other
> disks display (with mdadm -E):
> 0 Removed
> 1 Active
> 2 Faulty removed
> 3 Active
> 4 Spare
> That looks coherent for me, now.
>
> > So I suspect that device is badly confused and you probably want to zero
> > it's metadata ... but don't do that too hastily.
> >
> > All the other devices think the array is working correctly with a full
> > compliment of devices. However there is no device which claims to
> > be "RaidDevice 2" - except sdc1 and it is obviously confused..
> >
> > The device name listed in the table at the end of --examine output.
> > It is the name that the device had when the metadata was last written. And
> > device names can change on reboot.
> > The fact that the names don't line up suggest that the metadata hasn't been
> > written since the last reboot - so presumably you aren't really using the
> > array.(???)
> >
> > [the newer 1.x metadata format doesn't try to record the names of devices
> > in the superblock so it doesn't result in some of this confusion).
> >
> >
> > Based on your earlier email, it would appear that the device discovery for
> > some of your devices is happening in parallel at boot time, so or ordering
> > could be random - each time you boot you get a different order. This will
> > not confuse md or mdadm - they look at the content of the devices rather
> > than the name.
> > If you want a definitive name for each device, it might be a good idea to
> > look in /dev/disk/by-path or /dev/disk/by-id and use names from there.
> >
> > Could you please sent a complete output of:
> >
> > cat /proc/mdstat
> > mdadm -D /dev/md0
> > mdadm -E /dev/sd?1
> >
> > all collected at the same time. Then I will suggest if there is any action
> > you should take to repair anything.
>
> Here it is, thankyou for you help
>
I suggest you:
mdadm --zero /dev/sdb1
having first double-checked that sdb1 is the devices with Events of 154,
then
mdadm -S /dev/md0
mdadm -As /dev/md0
and let the array rebuild the spare.
Then check the data and make sure it is all good.
Then add /dev/sdb1 back in as the spare
mdadm /dev/md0 --add /dev/sdb1
and everything should be fine - providing you don't hit any hardware errors
etc.
NeilBrown
> mdstat:
> =====
> Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4]
> [raid10]
> md0 : inactive sdb1[2](S) sdf1[4](S) sdd1[3](S) sdc1[1](S) sde1[0](S)
> 2441919680 blocks
>
> unused devices: <none>
> ====
> obviously, mdadm -D /dev/md0 output nothing
>
> mdadm -E /dev/sd?1
> ====
> /dev/sdb1:
> Magic : a92b4efc
> Version : 0.90.00
> UUID : b784237b:5a021f4d:4cf004e3:2cb521cf
> Creation Time : Sun Jan 2 16:41:45 2011
> Raid Level : raid10
> Used Dev Size : 488383936 (465.76 GiB 500.11 GB)
> Array Size : 976767872 (931.52 GiB 1000.21 GB)
> Raid Devices : 4
> Total Devices : 5
> Preferred Minor : 0
>
> Update Time : Wed Mar 16 09:50:03 2011
> State : clean
> Active Devices : 1
> Working Devices : 1
> Failed Devices : 2
> Spare Devices : 0
> Checksum : ec151590 - correct
> Events : 154
>
> Layout : near=2
> Chunk Size : 64K
>
> Number Major Minor RaidDevice State
> this 2 8 65 2 active sync /dev/sde1
>
> 0 0 0 0 0 removed
> 1 1 0 0 1 faulty removed
> 2 2 8 65 2 active sync /dev/sde1
> 3 3 0 0 3 faulty removed
> /dev/sdc1:
> Magic : a92b4efc
> Version : 0.90.00
> UUID : b784237b:5a021f4d:4cf004e3:2cb521cf
> Creation Time : Sun Jan 2 16:41:45 2011
> Raid Level : raid10
> Used Dev Size : 488383936 (465.76 GiB 500.11 GB)
> Array Size : 976767872 (931.52 GiB 1000.21 GB)
> Raid Devices : 4
> Total Devices : 3
> Preferred Minor : 0
>
> Update Time : Fri Mar 18 16:37:45 2011
> State : clean
> Active Devices : 2
> Working Devices : 3
> Failed Devices : 1
> Spare Devices : 1
> Checksum : ec181672 - correct
> Events : 107
>
> Layout : near=2
> Chunk Size : 64K
>
> Number Major Minor RaidDevice State
> this 1 8 17 1 active sync /dev/sdb1
>
> 0 0 0 0 0 removed
> 1 1 8 17 1 active sync /dev/sdb1
> 2 2 0 0 2 faulty removed
> 3 3 8 49 3 active sync /dev/sdd1
> 4 4 8 33 4 spare /dev/sdc1
> /dev/sdd1:
> Magic : a92b4efc
> Version : 0.90.00
> UUID : b784237b:5a021f4d:4cf004e3:2cb521cf
> Creation Time : Sun Jan 2 16:41:45 2011
> Raid Level : raid10
> Used Dev Size : 488383936 (465.76 GiB 500.11 GB)
> Array Size : 976767872 (931.52 GiB 1000.21 GB)
> Raid Devices : 4
> Total Devices : 3
> Preferred Minor : 0
>
> Update Time : Fri Mar 18 16:37:45 2011
> State : clean
> Active Devices : 2
> Working Devices : 3
> Failed Devices : 1
> Spare Devices : 1
> Checksum : ec181696 - correct
> Events : 107
>
> Layout : near=2
> Chunk Size : 64K
>
> Number Major Minor RaidDevice State
> this 3 8 49 3 active sync /dev/sdd1
>
> 0 0 0 0 0 removed
> 1 1 8 17 1 active sync /dev/sdb1
> 2 2 0 0 2 faulty removed
> 3 3 8 49 3 active sync /dev/sdd1
> 4 4 8 33 4 spare /dev/sdc1
> /dev/sde1:
> Magic : a92b4efc
> Version : 0.90.00
> UUID : b784237b:5a021f4d:4cf004e3:2cb521cf
> Creation Time : Sun Jan 2 16:41:45 2011
> Raid Level : raid10
> Used Dev Size : 488383936 (465.76 GiB 500.11 GB)
> Array Size : 976767872 (931.52 GiB 1000.21 GB)
> Raid Devices : 4
> Total Devices : 5
> Preferred Minor : 0
>
> Update Time : Wed Mar 16 07:43:45 2011
> State : clean
> Active Devices : 4
> Working Devices : 5
> Failed Devices : 0
> Spare Devices : 1
> Checksum : ec14f740 - correct
> Events : 102
>
> Layout : near=2
> Chunk Size : 64K
>
> Number Major Minor RaidDevice State
> this 0 8 33 0 active sync /dev/sdc1
>
> 0 0 8 33 0 active sync /dev/sdc1
> 1 1 8 49 1 active sync /dev/sdd1
> 2 2 8 65 2 active sync /dev/sde1
> 3 3 8 81 3 active sync /dev/sdf1
> 4 4 8 97 4 spare
> /dev/sdf1:
> Magic : a92b4efc
> Version : 0.90.00
> UUID : b784237b:5a021f4d:4cf004e3:2cb521cf
> Creation Time : Sun Jan 2 16:41:45 2011
> Raid Level : raid10
> Used Dev Size : 488383936 (465.76 GiB 500.11 GB)
> Array Size : 976767872 (931.52 GiB 1000.21 GB)
> Raid Devices : 4
> Total Devices : 3
> Preferred Minor : 0
>
> Update Time : Fri Mar 18 16:37:45 2011
> State : clean
> Active Devices : 2
> Working Devices : 3
> Failed Devices : 1
> Spare Devices : 1
> Checksum : ec181682 - correct
> Events : 107
>
> Layout : near=2
> Chunk Size : 64K
>
> Number Major Minor RaidDevice State
> this 4 8 33 4 spare /dev/sdc1
>
> 0 0 0 0 0 removed
> 1 1 8 17 1 active sync /dev/sdb1
> 2 2 0 0 2 faulty removed
> 3 3 8 49 3 active sync /dev/sdd1
> 4 4 8 33 4 spare /dev/sdc1
> ====
>
>
>
> Xavier
> xavier@alternatif.org - 09 54 06 16 26
--
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
next prev parent reply other threads:[~2011-03-19 1:42 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-18 14:49 disk order problem in a raid 10 array Xavier Brochard
2011-03-18 17:22 ` hansbkk
2011-03-18 20:09 ` Xavier Brochard
2011-03-18 20:12 ` Xavier Brochard
2011-03-18 22:22 ` NeilBrown
2011-03-18 20:26 ` Adaptive throttling for RAID1 background resync Hari Subramanian
2011-03-18 20:28 ` Roberto Spadim
2011-03-18 20:31 ` Hari Subramanian
2011-03-18 20:36 ` Roberto Spadim
2011-03-18 20:54 ` Hari Subramanian
2011-03-18 21:02 ` Roberto Spadim
2011-03-18 22:11 ` NeilBrown
2011-03-21 21:02 ` Hari Subramanian
2011-03-18 22:14 ` disk order problem in a raid 10 array NeilBrown
[not found] ` <201103182350.19281.xavier@alternatif.org>
[not found] ` <20110319102039.52cc2282@notabene.brown>
2011-03-18 23:59 ` Xavier Brochard
2011-03-19 0:05 ` Xavier Brochard
2011-03-19 0:07 ` Roberto Spadim
2011-03-19 0:25 ` Xavier Brochard
2011-03-19 1:42 ` NeilBrown [this message]
2011-03-19 13:44 ` Xavier Brochard
2011-03-19 15:14 ` Xavier Brochard
2011-03-20 3:53 ` NeilBrown
2011-03-20 10:40 ` Xavier Brochard
2011-03-19 12:01 ` Xavier Brochard
-- strict thread matches above, loose matches on Subject: below --
2011-03-18 23:06 Xavier Brochard
2011-03-18 23:06 Xavier Brochard
2011-03-18 23:57 ` Roberto Spadim
2011-03-19 0:03 ` Xavier Brochard
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=20110319124247.41bac36a@notabene.brown \
--to=neilb@suse.de \
--cc=linux-raid@vger.kernel.org \
--cc=xavier@alternatif.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.