* RE: reaid problem at reboot
From: william L'Heureux @ 2011-06-22 1:50 UTC (permalink / raw)
To: philip; +Cc: linux-raid
In-Reply-To: <4E0146B6.40101@turmel.org>
for x in /dev/sd[abcdefghijkm]1 ; do echo "**** $x ****" ; dd if=$x skip=2056 count=2 2>/dev/null |strings ; done
**** /dev/sda1 ****
**** /dev/sdb1 ****
LVM2 x[5A%r0N*>
vgRAID60 {
id = "RUodpI-jXin-DEjs-fS3R-4hjA-hQ4l-41dAaJ"
seqno = 19
status = ["RESIZEABLE", "READ", "WRITE"]
flags = []
extent_size = 8192
max_lv = 0
max_pv = 0
physical_volumes {
pv0 {
id = "V5c1yI-XD3D-FXlB-VDYd-tUfo-eIUC-hXQfVW"
device = "/dev/md1"
status = ["ALLOCATABLE"]
flags = []
dev_size = 7799999488
pe_start = 512
pe_count = 952148
pv1 {
id = "BzZcan-uC9b-MQne-caBo-tYp3-9xkA-NnGuBE"
device = "/dev/md2"
status = ["ALLOCATABLE"]
flags = []
dev_size = 7799999488
pe_start = 512
pe_count = 952148
**** /dev/sdc1 ****
**** /dev/sdd1 ****
!HV]3$xK
M1N+>
vgRQID6 {
*= "RUodpI-jXin-D<
s-fC3R-$hjA=hQ4l-41dAaJ"
seqnoV
ctates =0["RESIZEABLE", "RE7
", 2WRIDE"]
jags = []
extent_
ze - 81)2
mqx_lv = 0
max_pv = F
phisicql_v
6wmes {
pv0 {
&"V5s1yI=XD3T-FXlB-VDYd-tUfo-eI#
-hXAfVW2
defice = "/dev/md1"
atuc = K"AL\
@ATABLE"]
flags =
duv_syze -V2814057984
pe_sta
= %12
`e_c
zjt = 953864
pv6[{
it = 2BzZs
n-uC9b-MQne-caBo-
Np3-)xkA=NnGeUA"
device = "/dev
stqtus0E"["ALLOCATABLE"]
ags0= [M
pize = 7814057984Z
e_sdart0= 5!q
pe_count = 95386
**** /dev/sde1 ****
**** /dev/sdf1 ****
**** /dev/sdg1 ****
LV]2 xK
A%r0N*>
vgRQID6 {
/= "RUodpI-jXin-Dz
s-fC3R-$hjA=hQ4l-41dAaJ"
seqnoV
stadus - ["RESIZEABLE", "R3
D",0"WRYTE"M
flags = []
extent)
ize0= 8!92
y_lv = 0
max_pv =.
pxysisal_f
mumes {
pv0 {
"V%c1yY-XD#D-FXlB-VDYd-tUfo-e?
C-hHQfVG"
duvice = "/dev/md1"
tates =0["A\LOCATABLE"]
flags K
tev_cize0= 7799999488
pe_st
t =0512
pe_sount = 952148
yd =0"BzJcan-uC9b-MQne-caBo[
Yp3=9xkQ-NnW
device = "/de
md22
sdatuc = ["ALLOCATABLE"]|
lagc = K]
duv_size = 779999948N
pe_ctard = %12
pe_count = 9521B
**** /dev/sdh1 ****
**** /dev/sdi1 ****
"RiodpI-jXin-
dAaJ"
seqn
a82j
SIfEABLE", "R
extent
max_pv =
pv0 {
B-jDYd-tUfo-e
/dev/md1"
ABpE"]
flags
40 7984
pe_st
53864
C9^-MQne-caBo
deJice = "/de
q82B
ALpOCATABLE"]
781405798
7m!_
_cSunt = 9538
**** /dev/sdj1 ****
LVM2 x[5A%r0N*>
vgRAID60 {
id = "RUodpI-jXin-DEjs-fS3R-4hjA-hQ4l-41dAaJ"
seqno = 2
status = ["RESIZEABLE", "READ", "WRITE"]
flags = []
extent_size = 8192
max_lv = 0
max_pv = 0
physical_volumes {
pv0 {
id = "V5c1yI-XD3D-FXlB-VDYd-tUfo-eIUC-hXQfVW"
device = "/dev/md1"
status = ["ALLOCATABLE"]
flags = []
dev_size = 7814057984
pe_start = 512
pe_count = 953864
pv1 {
id = "BzZcan-uC9b-MQne-caBo-tYp3-9xkA-NnGuBE"
device = "/dev/md2"
status = ["ALLOCATABLE"]
flags = []
dev_size = 7814057984
pe_start = 512
pe_count = 953864
**** /dev/sdk1 ****
"RiodpI-jXin-
dAaJ"
seqn
.[81Y
ESuZEABLE", "
= []
exten
max_pv
pv0 {
VDYd-tUfo-
"/dev/md1"
TA~LE"]
flags
99488
pe_s
952148
b-MQne-caB
6 pS
dYvice = "/d
"ApLOCATABLE"
_<$a
= 77999994
e__ount = 952
**** /dev/sdm1 ****
for x in /dev/sd[abcdefghijkm]1 ; do echo "**** $x ****" ; dd if=$x skip=2048 count=1 2>/dev/null |hexdump -C ; done
**** /dev/sda1 ****
00000000 00 00 c0 0f 10 00 c0 0f 20 00 c0 0f e0 02 00 20 |........ ...... |
00000010 00 00 05 00 00 00 00 00 00 00 00 00 00 20 92 26 |............. .&|
00000020 01 00 c0 0f 11 00 c0 0f 20 02 c0 0f 00 00 00 20 |........ ...... |
00000030 00 00 05 00 00 00 00 00 00 00 00 00 00 20 df 10 |............. ..|
00000040 02 00 c0 0f 12 00 c0 0f 20 04 c0 0f 00 00 00 20 |........ ...... |
00000050 00 00 05 00 00 00 00 00 00 00 00 00 00 20 b1 b1 |............. ..|
00000060 03 00 c0 0f 13 00 c0 0f 20 06 c0 0f 00 00 00 20 |........ ...... |
00000070 00 00 05 00 00 00 00 00 00 00 00 00 00 20 6a 11 |............. j.|
00000080 04 00 c0 0f 14 00 c0 0f 20 08 c0 0f 00 00 00 20 |........ ...... |
00000090 00 00 05 00 00 00 00 00 00 00 00 00 00 20 6e b3 |............. n.|
000000a0 05 00 c0 0f 15 00 c0 0f 20 0a c0 0f 00 00 00 20 |........ ...... |
000000b0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 b5 13 |............. ..|
000000c0 06 00 c0 0f 16 00 c0 0f 20 0c c0 0f 00 00 00 20 |........ ...... |
000000d0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 db b2 |............. ..|
000000e0 07 00 c0 0f 17 00 c0 0f 20 0e c0 0f 00 00 00 20 |........ ...... |
000000f0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 00 12 |............. ..|
00000100 08 00 c0 0f 18 00 c0 0f 20 10 c0 0f 00 00 00 20 |........ ...... |
00000110 00 00 05 00 00 00 00 00 00 00 00 00 00 20 d0 b6 |............. ..|
00000120 09 00 c0 0f 19 00 c0 0f 20 12 c0 0f 00 00 00 20 |........ ...... |
00000130 00 00 05 00 00 00 00 00 00 00 00 00 00 20 0b 16 |............. ..|
00000140 0a 00 c0 0f 1a 00 c0 0f 20 14 c0 0f 00 00 00 20 |........ ...... |
00000150 00 00 05 00 00 00 00 00 00 00 00 00 00 20 65 b7 |............. e.|
00000160 0b 00 c0 0f 1b 00 c0 0f 20 16 c0 0f 00 00 00 20 |........ ...... |
00000170 00 00 05 00 00 00 00 00 00 00 00 00 00 20 be 17 |............. ..|
00000180 0c 00 c0 0f 1c 00 c0 0f 20 18 c0 0f 00 00 00 20 |........ ...... |
00000190 00 00 05 00 00 00 00 00 00 00 00 00 00 20 ba b5 |............. ..|
000001a0 0d 00 c0 0f 1d 00 c0 0f 20 1a c0 0f 00 00 00 20 |........ ...... |
000001b0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 61 15 |............. a.|
000001c0 0e 00 c0 0f 1e 00 c0 0f 20 1c c0 0f 00 00 00 20 |........ ...... |
000001d0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 0f b4 |............. ..|
000001e0 0f 00 c0 0f 1f 00 c0 0f 20 1e c0 0f 00 00 00 20 |........ ...... |
000001f0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 d4 14 |............. ..|
00000200
**** /dev/sdb1 ****
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
**** /dev/sdc1 ****
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
**** /dev/sdd1 ****
00000000 00 00 c0 0f 10 00 c0 0f 20 00 c0 0f e0 02 00 20 |........ ...... |
00000010 00 00 05 00 00 00 00 00 00 00 00 00 00 20 92 26 |............. .&|
00000020 01 00 c0 0f 11 00 c0 0f 20 02 c0 0f 00 00 00 20 |........ ...... |
00000030 00 00 05 00 00 00 00 00 00 00 00 00 00 20 df 10 |............. ..|
00000040 02 00 c0 0f 12 00 c0 0f 20 04 c0 0f 00 00 00 20 |........ ...... |
00000050 00 00 05 00 00 00 00 00 00 00 00 00 00 20 b1 b1 |............. ..|
00000060 03 00 c0 0f 13 00 c0 0f 20 06 c0 0f 00 00 00 20 |........ ...... |
00000070 00 00 05 00 00 00 00 00 00 00 00 00 00 20 6a 11 |............. j.|
00000080 04 00 c0 0f 14 00 c0 0f 20 08 c0 0f 00 00 00 20 |........ ...... |
00000090 00 00 05 00 00 00 00 00 00 00 00 00 00 20 6e b3 |............. n.|
000000a0 05 00 c0 0f 15 00 c0 0f 20 0a c0 0f 00 00 00 20 |........ ...... |
000000b0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 b5 13 |............. ..|
000000c0 06 00 c0 0f 16 00 c0 0f 20 0c c0 0f 00 00 00 20 |........ ...... |
000000d0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 db b2 |............. ..|
000000e0 07 00 c0 0f 17 00 c0 0f 20 0e c0 0f 00 00 00 20 |........ ...... |
000000f0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 00 12 |............. ..|
00000100 08 00 c0 0f 18 00 c0 0f 20 10 c0 0f 00 00 00 20 |........ ...... |
00000110 00 00 05 00 00 00 00 00 00 00 00 00 00 20 d0 b6 |............. ..|
00000120 09 00 c0 0f 19 00 c0 0f 20 12 c0 0f 00 00 00 20 |........ ...... |
00000130 00 00 05 00 00 00 00 00 00 00 00 00 00 20 0b 16 |............. ..|
00000140 0a 00 c0 0f 1a 00 c0 0f 20 14 c0 0f 00 00 00 20 |........ ...... |
00000150 00 00 05 00 00 00 00 00 00 00 00 00 00 20 65 b7 |............. e.|
00000160 0b 00 c0 0f 1b 00 c0 0f 20 16 c0 0f 00 00 00 20 |........ ...... |
00000170 00 00 05 00 00 00 00 00 00 00 00 00 00 20 be 17 |............. ..|
00000180 0c 00 c0 0f 1c 00 c0 0f 20 18 c0 0f 00 00 00 20 |........ ...... |
00000190 00 00 05 00 00 00 00 00 00 00 00 00 00 20 ba b5 |............. ..|
000001a0 0d 00 c0 0f 1d 00 c0 0f 20 1a c0 0f 00 00 00 20 |........ ...... |
000001b0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 61 15 |............. a.|
000001c0 0e 00 c0 0f 1e 00 c0 0f 20 1c c0 0f 00 00 00 20 |........ ...... |
000001d0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 0f b4 |............. ..|
000001e0 0f 00 c0 0f 1f 00 c0 0f 20 1e c0 0f 00 00 00 20 |........ ...... |
000001f0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 d4 14 |............. ..|
00000200
**** /dev/sde1 ****
00000000 00 00 c0 13 10 00 c0 13 20 00 c0 13 e0 04 00 20 |........ ...... |
00000010 00 00 05 00 00 00 00 00 00 00 00 00 00 20 e0 f7 |............. ..|
00000020 01 00 c0 13 11 00 c0 13 20 02 c0 13 00 00 00 20 |........ ...... |
00000030 00 00 05 00 00 00 00 00 00 00 00 00 00 20 4e 60 |............. N`|
00000040 02 00 c0 13 12 00 c0 13 20 04 c0 13 1f 04 00 20 |........ ...... |
00000050 00 00 05 00 00 00 00 00 00 00 00 00 00 20 55 d2 |............. U.|
00000060 03 00 c0 13 13 00 c0 13 20 06 c0 13 50 00 00 20 |........ ...P.. |
00000070 00 00 05 00 00 00 00 00 00 00 00 00 00 20 ea 70 |............. .p|
00000080 04 00 c0 13 14 00 c0 13 20 08 c0 13 00 00 00 20 |........ ...... |
00000090 00 00 05 00 00 00 00 00 00 00 00 00 00 20 ff c3 |............. ..|
000000a0 05 00 c0 13 15 00 c0 13 20 0a c0 13 00 00 00 20 |........ ...... |
000000b0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 24 63 |............. $c|
000000c0 06 00 c0 13 16 00 c0 13 20 0c c0 13 00 00 00 20 |........ ...... |
000000d0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 4a c2 |............. J.|
000000e0 07 00 c0 13 17 00 c0 13 20 0e c0 13 7f 00 00 20 |........ ...... |
000000f0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 b8 ae |............. ..|
00000100 08 00 c0 13 18 00 c0 13 20 10 c0 13 00 00 00 20 |........ ...... |
00000110 00 00 05 00 00 00 00 00 00 00 00 00 00 20 41 c6 |............. A.|
00000120 09 00 c0 13 19 00 c0 13 20 12 c0 13 00 00 00 20 |........ ...... |
00000130 00 00 05 00 00 00 00 00 00 00 00 00 00 20 9a 66 |............. .f|
00000140 0a 00 c0 13 1a 00 c0 13 20 14 c0 13 00 00 00 20 |........ ...... |
00000150 00 00 05 00 00 00 00 00 00 00 00 00 00 20 f4 c7 |............. ..|
00000160 0b 00 c0 13 1b 00 c0 13 20 16 c0 13 00 00 00 20 |........ ...... |
00000170 00 00 05 00 00 00 00 00 00 00 00 00 00 20 2f 67 |............. /g|
00000180 0c 00 c0 13 1c 00 c0 13 20 18 c0 13 00 00 00 20 |........ ...... |
00000190 00 00 05 00 00 00 00 00 00 00 00 00 00 20 2b c5 |............. +.|
000001a0 0d 00 c0 13 1d 00 c0 13 20 1a c0 13 00 00 00 20 |........ ...... |
000001b0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 f0 65 |............. .e|
000001c0 0e 00 c0 13 1e 00 c0 13 20 1c c0 13 00 00 00 20 |........ ...... |
000001d0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 9e c4 |............. ..|
000001e0 0f 00 c0 13 1f 00 c0 13 20 1e c0 13 00 00 00 20 |........ ...... |
000001f0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 45 64 |............. Ed|
00000200
**** /dev/sdf1 ****
00000000 00 00 c0 03 10 00 c0 03 20 00 c0 03 0c 08 00 20 |........ ...... |
00000010 00 00 05 00 00 00 00 00 00 00 00 00 00 20 a7 fc |............. ..|
00000020 01 00 c0 03 11 00 c0 03 20 02 c0 03 00 00 00 20 |........ ...... |
00000030 00 00 05 00 00 00 00 00 00 00 00 00 00 20 38 cd |............. 8.|
00000040 02 00 c0 03 12 00 c0 03 20 04 c0 03 00 00 00 20 |........ ...... |
00000050 00 00 05 00 00 00 00 00 00 00 00 00 00 20 56 6c |............. Vl|
00000060 03 00 c0 03 13 00 c0 03 20 06 c0 03 00 00 00 20 |........ ...... |
00000070 00 00 05 00 00 00 00 00 00 00 00 00 00 20 8d cc |............. ..|
00000080 04 00 c0 03 14 00 c0 03 20 08 c0 03 00 00 00 20 |........ ...... |
00000090 00 00 05 00 00 00 00 00 00 00 00 00 00 20 89 6e |............. .n|
000000a0 05 00 c0 03 15 00 c0 03 20 0a c0 03 00 00 00 20 |........ ...... |
000000b0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 52 ce |............. R.|
000000c0 06 00 c0 03 16 00 c0 03 20 0c c0 03 00 00 00 20 |........ ...... |
000000d0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 3c 6f |............. <o|
000000e0 07 00 c0 03 17 00 c0 03 20 0e c0 03 00 00 00 20 |........ ...... |
000000f0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 e7 cf |............. ..|
00000100 08 00 c0 03 18 00 c0 03 20 10 c0 03 00 00 00 20 |........ ...... |
00000110 00 00 05 00 00 00 00 00 00 00 00 00 00 20 37 6b |............. 7k|
00000120 09 00 c0 03 19 00 c0 03 20 12 c0 03 00 00 00 20 |........ ...... |
00000130 00 00 05 00 00 00 00 00 00 00 00 00 00 20 ec cb |............. ..|
00000140 0a 00 c0 03 1a 00 c0 03 20 14 c0 03 00 00 00 20 |........ ...... |
00000150 00 00 05 00 00 00 00 00 00 00 00 00 00 20 82 6a |............. .j|
00000160 0b 00 c0 03 1b 00 c0 03 20 16 c0 03 00 00 00 20 |........ ...... |
00000170 00 00 05 00 00 00 00 00 00 00 00 00 00 20 59 ca |............. Y.|
00000180 0c 00 c0 03 1c 00 c0 03 20 18 c0 03 00 00 00 20 |........ ...... |
00000190 00 00 05 00 00 00 00 00 00 00 00 00 00 20 5d 68 |............. ]h|
000001a0 0d 00 c0 03 1d 00 c0 03 20 1a c0 03 00 00 00 20 |........ ...... |
000001b0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 86 c8 |............. ..|
000001c0 0e 00 c0 03 1e 00 c0 03 20 1c c0 03 00 00 00 20 |........ ...... |
000001d0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 e8 69 |............. .i|
000001e0 0f 00 c0 03 1f 00 c0 03 20 1e c0 03 00 00 00 20 |........ ...... |
000001f0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 33 c9 |............. 3.|
00000200
**** /dev/sdg1 ****
00000000 00 00 00 10 00 00 00 10 00 00 00 10 ec 0c 00 00 |................|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 47 0b |..............G.|
00000020 00 00 00 10 00 00 00 10 00 00 00 10 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 76 ad |..............v.|
00000040 00 00 00 10 00 00 00 10 00 00 00 10 1f 04 00 00 |................|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 be |................|
00000060 00 00 00 10 00 00 00 10 00 00 00 10 50 00 00 00 |............P...|
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 67 bc |..............g.|
00000080 00 00 00 10 00 00 00 10 00 00 00 10 00 00 00 00 |................|
00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 76 ad |..............v.|
000000a0 00 00 00 10 00 00 00 10 00 00 00 10 00 00 00 00 |................|
000000b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 76 ad |..............v.|
000000c0 00 00 00 10 00 00 00 10 00 00 00 10 00 00 00 00 |................|
000000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 76 ad |..............v.|
000000e0 00 00 00 10 00 00 00 10 00 00 00 10 7f 00 00 00 |................|
000000f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5f 61 |.............._a|
00000100 00 00 00 10 00 00 00 10 00 00 00 10 00 00 00 00 |................|
00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 76 ad |..............v.|
00000120 00 00 00 10 00 00 00 10 00 00 00 10 00 00 00 00 |................|
00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 76 ad |..............v.|
00000140 00 00 00 10 00 00 00 10 00 00 00 10 00 00 00 00 |................|
00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 76 ad |..............v.|
00000160 00 00 00 10 00 00 00 10 00 00 00 10 00 00 00 00 |................|
00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 76 ad |..............v.|
00000180 00 00 00 10 00 00 00 10 00 00 00 10 00 00 00 00 |................|
00000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 76 ad |..............v.|
000001a0 00 00 00 10 00 00 00 10 00 00 00 10 00 00 00 00 |................|
000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 76 ad |..............v.|
000001c0 00 00 00 10 00 00 00 10 00 00 00 10 00 00 00 00 |................|
000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 76 ad |..............v.|
000001e0 00 00 00 10 00 00 00 10 00 00 00 10 00 00 00 00 |................|
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 76 ad |..............v.|
00000200
**** /dev/sdh1 ****
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
**** /dev/sdi1 ****
00000000 00 00 4e 78 80 00 4e 78 1d 00 4e 78 53 10 00 1d |..Nx..Nx..NxS...|
00000010 00 00 28 00 00 00 00 00 00 00 00 00 00 1d e4 2d |..(............-|
00000020 08 00 4e 78 88 00 4e 78 1d 10 4e 78 00 00 00 1d |..Nx..Nx..Nx....|
00000030 00 00 28 00 00 00 00 00 00 00 00 00 00 1d b6 80 |..(.............|
00000040 10 00 4e 78 90 00 4e 78 1d 20 4e 78 00 00 00 1d |..Nx..Nx. Nx....|
00000050 00 00 28 00 00 00 00 00 00 00 00 00 00 1d e1 e1 |..(.............|
00000060 18 00 4e 78 98 00 4e 78 1d 30 4e 78 00 00 00 1d |..Nx..Nx.0Nx....|
00000070 00 00 28 00 00 00 00 00 00 00 00 00 00 1d 77 88 |..(...........w.|
00000080 20 00 4e 78 a0 00 4e 78 1d 40 4e 78 00 00 00 1d | .Nx..Nx.@Nx....|
00000090 00 00 28 00 00 00 00 00 00 00 00 00 00 1d 57 f1 |..(...........W.|
000000a0 28 00 4e 78 a8 00 4e 78 1d 50 4e 78 00 00 00 1d |(.Nx..Nx.PNx....|
000000b0 00 00 28 00 00 00 00 00 00 00 00 00 00 1d c1 98 |..(.............|
000000c0 30 00 4e 78 b0 00 4e 78 1d 60 4e 78 00 00 00 1d |0.Nx..Nx.`Nx....|
000000d0 00 00 28 00 00 00 00 00 00 00 00 00 00 1d 96 f9 |..(.............|
000000e0 38 00 4e 78 b8 00 4e 78 1d 70 4e 78 00 00 00 1d |8.Nx..Nx.pNx....|
000000f0 00 00 28 00 00 00 00 00 00 00 00 00 00 1d 00 90 |..(.............|
00000100 40 00 4e 78 c0 00 4e 78 1d 80 4e 78 00 00 00 1d |@.Nx..Nx..Nx....|
00000110 00 00 28 00 00 00 00 00 00 00 00 00 00 1d ce d9 |..(.............|
00000120 48 00 4e 78 c8 00 4e 78 1d 90 4e 78 00 00 00 1d |H.Nx..Nx..Nx....|
00000130 00 00 28 00 00 00 00 00 00 00 00 00 00 1d 58 b0 |..(...........X.|
00000140 50 00 4e 78 d0 00 4e 78 1d a0 4e 78 00 00 00 1d |P.Nx..Nx..Nx....|
00000150 00 00 28 00 00 00 00 00 00 00 00 00 00 1d 0f d1 |..(.............|
00000160 58 00 4e 78 d8 00 4e 78 1d b0 4e 78 00 00 00 1d |X.Nx..Nx..Nx....|
00000170 00 00 28 00 00 00 00 00 00 00 00 00 00 1d 99 b8 |..(.............|
00000180 60 00 4e 78 e0 00 4e 78 1d c0 4e 78 00 00 00 1d |`.Nx..Nx..Nx....|
00000190 00 00 28 00 00 00 00 00 00 00 00 00 00 1d b9 c1 |..(.............|
000001a0 68 00 4e 78 e8 00 4e 78 1d d0 4e 78 00 00 00 1d |h.Nx..Nx..Nx....|
000001b0 00 00 28 00 00 00 00 00 00 00 00 00 00 1d 2f a8 |..(.........../.|
000001c0 70 00 4e 78 f0 00 4e 78 1d e0 4e 78 00 00 00 1d |p.Nx..Nx..Nx....|
000001d0 00 00 28 00 00 00 00 00 00 00 00 00 00 1d 78 c9 |..(...........x.|
000001e0 78 00 4e 78 f8 00 4e 78 1d f0 4e 78 00 00 00 1d |x.Nx..Nx..Nx....|
000001f0 00 00 28 00 00 00 00 00 00 00 00 00 00 1d ee a0 |..(.............|
00000200
**** /dev/sdj1 ****
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
**** /dev/sdk1 ****
00000000 00 00 69 94 c0 00 69 94 9d 00 69 94 63 00 00 9d |..i...i...i.c...|
00000010 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d f5 3c |..<............<|
00000020 0c 00 69 94 cc 00 69 94 9d 18 69 94 00 00 00 9d |..i...i...i.....|
00000030 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d aa 34 |..<............4|
00000040 18 00 69 94 d8 00 69 94 9d 30 69 94 f8 20 00 9d |..i...i..0i.. ..|
00000050 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d d7 73 |..<............s|
00000060 14 00 69 94 d4 00 69 94 9d 28 69 94 ba 00 00 9d |..i...i..(i.....|
00000070 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d 0d b0 |..<.............|
00000080 30 00 69 94 f0 00 69 94 9d 60 69 94 00 00 00 9d |0.i...i..`i.....|
00000090 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d b5 f3 |..<.............|
000000a0 3c 00 69 94 fc 00 69 94 9d 78 69 94 00 00 00 9d |<.i...i..xi.....|
000000b0 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d 68 20 |..<...........h |
000000c0 28 00 69 94 e8 00 69 94 9d 50 69 94 00 00 00 9d |(.i...i..Pi.....|
000000d0 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d 9a ff |..<.............|
000000e0 24 00 69 94 e4 00 69 94 9d 48 69 94 df 00 00 9d |$.i...i..Hi.....|
000000f0 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d 12 02 |..<.............|
00000100 60 00 69 94 a0 00 69 94 9d c0 69 94 00 00 00 9d |`.i...i...i.....|
00000110 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d ee cf |..<.............|
00000120 6c 00 69 94 ac 00 69 94 9d d8 69 94 00 00 00 9d |l.i...i...i.....|
00000130 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d 33 1c |..<...........3.|
00000140 78 00 69 94 b8 00 69 94 9d f0 69 94 00 00 00 9d |x.i...i...i.....|
00000150 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d c1 c3 |..<.............|
00000160 74 00 69 94 b4 00 69 94 9d e8 69 94 00 00 00 9d |t.i...i...i.....|
00000170 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d 1c 10 |..<.............|
00000180 50 00 69 94 90 00 69 94 9d a0 69 94 00 00 00 9d |P.i...i...i.....|
00000190 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d 2c db |..<...........,.|
000001a0 5c 00 69 94 9c 00 69 94 9d b8 69 94 00 00 00 9d |\.i...i...i.....|
000001b0 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d f1 08 |..<.............|
000001c0 48 00 69 94 88 00 69 94 9d 90 69 94 00 00 00 9d |H.i...i...i.....|
000001d0 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d 03 d7 |..<.............|
000001e0 44 00 69 94 84 00 69 94 9d 88 69 94 00 00 00 9d |D.i...i...i.....|
000001f0 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d de 04 |..<.............|
00000200
**** /dev/sdm1 ****
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
btw, /dev/md1 is fine 100%
the drives for /dev/md0 --> 'a', 'c', 'd', 'h', 'i', 'j'
--
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
^ permalink raw reply
* Re: reaid problem at reboot
From: Phil Turmel @ 2011-06-22 1:34 UTC (permalink / raw)
To: william L'Heureux; +Cc: linux-raid
In-Reply-To: <BAY158-w3076B56F0F37E7F3DA4866C0500@phx.gbl>
Hi William,
On 06/21/2011 09:00 PM, william L'Heureux wrote:
>
> for x in /dev/sd[abcdefghijkm] ; do echo "**** $x ****" ; dd if=$x skip=2056 count=2 2>/dev/null |strings ; done
> **** /dev/sda ****
> -BILLSSHACK:0
> /4o.
> **** /dev/sdb ****
> billsshack:3
> **** /dev/sdc ****
> -BILLSSHACK:0
> **** /dev/sdd ****
> -BILLSSHACK:0
> CgW:
> **** /dev/sde ****
> billsshack:3
> **** /dev/sdf ****
> billsshack:3
> **** /dev/sdg ****
> billsshack:3
> <: L
> **** /dev/sdh ****
> -BILLSSHACK:0
> **** /dev/sdi ****
> -BILLSSHACK:0
> **** /dev/sdj ****
> -BILLSSHACK:0
> **** /dev/sdk ****
> billsshack:3
> **** /dev/sdm ****
> billsshack:3
> Zm$8 2
Hmmm. Not what I expected. Ah! Missing "1". Try both of these instead:
for x in /dev/sd[abcdefghijkm]1 ; do echo "**** $x ****" ; dd if=$x skip=2056 count=2 2>/dev/null |strings ; done
for x in /dev/sd[abcdefghijkm]1 ; do echo "**** $x ****" ; dd if=$x skip=2048 count=1 2>/dev/null |hexdump -C ; done
Phil
^ permalink raw reply
* RE: reaid problem at reboot
From: william L'Heureux @ 2011-06-22 1:00 UTC (permalink / raw)
To: philip; +Cc: linux-raid
In-Reply-To: <4E0113FE.503@turmel.org>
for x in /dev/sd[abcdefghijkm] ; do echo "**** $ x ****" ; dd if=$x skip=2056 count=2 2>/dev/null |strings ; done
**** /dev/sda ****
-BILLSSHACK:0
/4o.
**** /dev/sdb ****
billsshack:3
**** /dev/sdc ****
-BILLSSHACK:0
**** /dev/sdd ****
-BILLSSHACK:0
CgW:
**** /dev/sde ****
billsshack:3
**** /dev/sdf ****
billsshack:3
**** /dev/sdg ****
billsshack:3
<: L
**** /dev/sdh ****
-BILLSSHACK:0
**** /dev/sdi ****
-BILLSSHACK:0
**** /dev/sdj ****
-BILLSSHACK:0
**** /dev/sdk ****
billsshack:3
**** /dev/sdm ****
billsshack:3
Zm$8 2
Thanks
--
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
^ permalink raw reply
* 10x2TB RAID6
From: Manny Street @ 2011-06-21 23:59 UTC (permalink / raw)
To: linux-raid
[-- Attachment #1: Type: text/plain, Size: 11213 bytes --]
linux-raid@vger.kernel.org
Neil Brown,
I've posted to your webpage (http://neil.brown.name/blog/20090817000931)
in the past, so I hope you don't mind too much if I ask you for advice...
even if your not overly interested since the array failed during "normal"
use and not a conversion or grow.
I have a 10x2TB RAID6 array and I notice three drives have a different
"Event id" than the other 7 drives does this imply I'm "out of luck?".
*UPDATE* just noticed one of the three drives was a "spare" (why the same
event id?)
Do you think the array will just "start up" if I try to assemble it? Minus
2drives? Did the array not "freeze" after the 1st error?
I haven't tried anything yet... other than booting the machine after
renaming the mdadm.conf file (I expected this to prevent the array from
starting, however, a small 150G array started, maybe I needed to comment
out the entries rather than rename the file).
I have 8 ST32000542AS drives hanging off an "AOC-SASLP-MV8" card and 4
others on the motherboard ports (boot+spare) I think the 8 on the
raid-card drives went offline. All drives appear to have come back after
reboot.
I can provide you with more details, logs or even a shell "login" if you
like.
Note: after the *update* comment (spare) things are looking less dire but
any reassurance is appreciated.
Thank you,
-mann
mdadm -Evs
ARRAY /dev/md/127 level=raid6 metadata=1.2 num-devices=10
UUID=1747a894:8c1b4ea6:78d906f1:e0012a25 name=midori:127
spares=1
devices=/dev/sdl1,/dev/sdk1,/dev/sdj1,/dev/sdi1,/dev/sdh1,/dev/sdg1,/dev/sdf1,/dev/sde1,/dev/sdd3,/dev/sdb3,/dev/sdc3
ARRAY /dev/md/128 level=raid0 metadata=1.2 num-devices=6
UUID=b941a4ef:a119f0a7:5b9a19de:066487fd name=midori.gmind.org:128
devices=/dev/sdl2,/dev/sdk2,/dev/sdj2,/dev/sdi2,/dev/sdh2,/dev/sdg2
cat /proc/mdstat
# at time of failure #
Personalities : [raid0] [raid6] [raid5] [raid4]
md128 : active raid0 sdk2[5] sdl2[3] sdi2[2] sdg2[0] sdh2[1] sdj2[4]
154263552 blocks super 1.2 512k chunks
md127 : active raid6 sdk1[8](F) sdi1[3](F) sdl1[7](F) sdf1[4](F)
sdg1[6](F) sde1[2](F) sdh1[5](F) sdj1[0](F) sdb3[9] sdd3[11](S) sdc3[10]
15422390272 blocks super 1.2 level 6, 512k chunk, algorithm 2 [10/2]
[________UU]
unused devices: <none>
# after reboot #
Personalities : [raid0]
md126 : active raid0 sdl2[3] sdh2[1] sdk2[5] sdj2[4] sdg2[0] sdi2[2]
154263552 blocks super 1.2 512k chunks
md127 : inactive sdf1[4](S) sdh1[5](S) sdb3[9](S) sdi1[3](S) sdj1[0](S)
sdd3[11](S) sdl1[7](S) sde1[2](S) sdg1[6](S) sdk1[8](S) sdc3[10](S)
21205788389 blocks super 1.2
unused devices: <none>
/dev/mapper/vg_media-lv_repo01:
Version : 1.2
Creation Time : Sun Oct 3 18:37:02 2010
Raid Level : raid6
Array Size : 15422357504 (14707.91 GiB 15792.49 GB)
Used Dev Size : unknown
Raid Devices : 10
Total Devices : 11
Persistence : Superblock is persistent
Update Time : Tue Jun 21 00:15:45 2011
State : clean, FAILED
Active Devices : 2
Working Devices : 3
Failed Devices : 8
Spare Devices : 1
Layout : left-symmetric
Chunk Size : 512K
Name : midori:127
UUID : 1747a894:8c1b4ea6:78d906f1:e0012a25
Events : 120973
Number Major Minor RaidDevice State
0 0 0 0 removed
1 0 0 1 removed
2 0 0 2 removed
3 0 0 3 removed
4 0 0 4 removed
5 0 0 5 removed
6 0 0 6 removed
7 0 0 7 removed
9 8 19 8 active sync /dev/sdb3
10 8 35 9 active sync /dev/sdc3
0 8 145 - faulty spare /dev/sdj1
2 8 65 - faulty spare /dev/sde1
3 8 129 - faulty spare /dev/sdi1
4 8 81 - faulty spare /dev/sdf1
5 8 113 - faulty spare /dev/sdh1
6 8 97 - faulty spare /dev/sdg1
7 8 177 - faulty spare /dev/sdl1
8 8 161 - faulty spare /dev/sdk1
11 8 51 - spare /dev/sdd3
/dev/sdf1:
Array UUID : 1747a894:8c1b4ea6:78d906f1:e0012a25
Device UUID : 4d6a2158:b7fa56b2:214613af:69af783c
Checksum : 2510e6ed - correct
Events : 120904
Device Role : Active device 4
/dev/sdh1:
Array UUID : 1747a894:8c1b4ea6:78d906f1:e0012a25
Device UUID : b2a48e12:796b2c18:376beed8:74596771
Checksum : a41d6455 - correct
Events : 120904
Device Role : Active device 5
/dev/sdb3:
Array UUID : 1747a894:8c1b4ea6:78d906f1:e0012a25
Device UUID : e3834a2e:f8949e75:b26d1c5b:8631dbd9
Checksum : 7e35341 - correct
Events : 121003
Device Role : Active device 8
/dev/sdi1:
Array UUID : 1747a894:8c1b4ea6:78d906f1:e0012a25
Device UUID : d9b17712:cd167319:c17dcfc3:d847fcd2
Checksum : f1c31a9c - correct
Events : 120904
Device Role : Active device 3
/dev/sdj1:
Array UUID : 1747a894:8c1b4ea6:78d906f1:e0012a25
Device UUID : f1cb78ca:df118e47:57ade846:740e0c47
Checksum : cf0825f5 - correct
Events : 120904
Device Role : Active device 0
/dev/sdd3:
Array UUID : 1747a894:8c1b4ea6:78d906f1:e0012a25
Device UUID : a166f386:a6aa95dc:7f7ea369:3226d7ff
Checksum : fc065128 - correct
Events : 121003
/dev/sdl1:
Array UUID : 1747a894:8c1b4ea6:78d906f1:e0012a25
Device UUID : 7e5d9ed7:13fe2b3e:acbe1b4a:1ab3f660
Checksum : efe959b8 - correct
Events : 120904
Device Role : Active device 1
/dev/sde1:
Array UUID : 1747a894:8c1b4ea6:78d906f1:e0012a25
Device UUID : 3ee69896:cea55b57:229052b4:f5ca02cf
Checksum : a0567380 - correct
Events : 120904
Device Role : Active device 2
/dev/sdg1:
Array UUID : 1747a894:8c1b4ea6:78d906f1:e0012a25
Device UUID : 1035f17d:79452818:33fd5c41:dcab73ab
Checksum : b1f6aff8 - correct
Events : 120904
Device Role : Active device 6
/dev/sdk1:
Array UUID : 1747a894:8c1b4ea6:78d906f1:e0012a25
Device UUID : cafe0241:222eb745:0bf1d0f2:c66f0c09
Checksum : b1a41a1f - correct
Events : 120904
Device Role : Active device 7
/dev/sdc3:
Array UUID : 1747a894:8c1b4ea6:78d906f1:e0012a25
Device UUID : 746265e7:475ba235:dc367ab3:82f482a4
Checksum : a4078448 - correct
Events : 121003
Device Role : Active device 9
Jun 20 23:34:57 midori kernel: ata13: translated ATA stat/err 0x01/04 to
SCSI SK/ASC/ASCQ 0xb/00/00
Jun 20 23:34:57 midori kernel: ata13: status=0x01 { Error }
Jun 20 23:34:57 midori kernel: ata13: error=0x04 { DriveStatusError }
Jun 20 23:34:57 midori kernel: sd 6:0:6:0: [sdk] Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
Jun 20 23:34:57 midori kernel: sd 6:0:6:0: [sdk] Sense Key : Aborted
Command [current] [descriptor]
Jun 20 23:34:57 midori kernel: Descriptor sense data with sense
descriptors (in hex):
Jun 20 23:34:57 midori kernel: 72 0b 00 00 00 00 00 0c 00 0a 80 00
00 00 00 00
Jun 20 23:34:57 midori kernel: 00 00 00 56
Jun 20 23:34:57 midori kernel: sd 6:0:6:0: [sdk] Add. Sense: No
additional sense information
Jun 20 23:34:57 midori kernel: sd 6:0:6:0: [sdk] CDB: Write(10): 2a 00 a1
3f e0 3f 00 02 00 00
Jun 20 23:34:57 midori kernel: end_request: I/O error, dev sdk, sector
2705317951
Jun 20 23:34:57 midori kernel: md/raid:md127: Disk failure on sdk1,
disabling device.
Jun 20 23:34:57 midori kernel: <1>md/raid:md127: Operation continuing on 9
devices.
Jun 20 23:34:57 midori kernel: ata13: translated ATA stat/err 0x01/04 to
SCSI SK/ASC/ASCQ 0xb/00/00
Jun 20 23:34:57 midori kernel: ata13: status=0x01 { Error }
Jun 20 23:34:57 midori kernel: ata13: error=0x04 { DriveStatusError }
Jun 20 23:34:57 midori kernel: sd 6:0:6:0: [sdk] Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
Jun 20 23:34:57 midori kernel: sd 6:0:6:0: [sdk] Sense Key : Aborted
Command [current] [descriptor]
Jun 20 23:34:57 midori kernel: Descriptor sense data with sense
descriptors (in hex):
Jun 20 23:34:57 midori kernel: 72 0b 00 00 00 00 00 0c 00 0a 80 00
00 00 00 00
Jun 20 23:34:57 midori kernel: 00 00 00 56
Jun 20 23:34:57 midori kernel: sd 6:0:6:0: [sdk] Add. Sense: No
additional sense information
Jun 20 23:34:57 midori kernel: sd 6:0:6:0: [sdk] CDB: Read(10): 28 00 a1
3f de 5f 00 01 e0 00
Jun 20 23:34:57 midori kernel: end_request: I/O error, dev sdk, sector
2705317471
Jun 20 23:35:27 midori kernel: INFO: task kworker/u:7:345 blocked for more
than 120 seconds.
Jun 20 23:35:27 midori kernel: "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jun 20 23:35:27 midori kernel: kworker/u:7 D 0000000000000000 0
345 2 0x00000000
Jun 20 23:35:27 midori kernel: ffff88003716ba10 0000000000000046
ffff88003965aa00 ffff88003716a010
Jun 20 23:35:27 midori kernel: ffff88003716bfd8 0000000000014940
ffff88003711ae60 ffff88003711b218
Jun 20 23:35:27 midori kernel: ffff88003711b210 0000000000014940
0000000000014940 ffff88003716bfd8
Jun 20 23:35:27 midori kernel: Call Trace:
Jun 20 23:35:27 midori kernel: [<ffffffffa030bb9a>]
get_active_stripe+0x2c2/0x660 [raid456]
Jun 20 23:35:27 midori kernel: [<ffffffff81048abb>] ?
default_wake_function+0x0/0x14
Jun 20 23:35:27 midori kernel: [<ffffffffa030f2ba>]
make_request+0x21e/0x487 [raid456]
Jun 20 23:35:27 midori kernel: [<ffffffff8106799b>] ?
autoremove_wake_function+0x0/0x39
Jun 20 23:35:27 midori kernel: [<ffffffff81347c06>]
md_make_request+0xd4/0x1dc
Jun 20 23:35:27 midori kernel: [<ffffffff810c8ebf>] ?
mempool_alloc_slab+0x15/0x17
Jun 20 23:35:27 midori kernel: [<ffffffff810c8fad>] ?
mempool_alloc+0x71/0x12a
Jun 20 23:35:27 midori kernel: [<ffffffff811e3d2c>]
generic_make_request+0x2da/0x35e
Jun 20 23:35:27 midori kernel: [<ffffffff813537b1>] __map_bio+0xa2/0xfe
Jun 20 23:35:27 midori kernel: [<ffffffff81354fad>]
__split_and_process_bio+0x2a2/0x55e
Jun 20 23:35:27 midori kernel: [<ffffffff8100a60e>] ?
apic_timer_interrupt+0xe/0x20
Jun 20 23:35:27 midori kernel: [<ffffffff8135560f>] dm_wq_work+0x151/0x182
Jun 20 23:35:27 midori kernel: [<ffffffff813554be>] ? dm_wq_work+0x0/0x182
Jun 20 23:35:27 midori kernel: [<ffffffff810627c4>]
process_one_work+0x1a5/0x2b3
Jun 20 23:35:27 midori kernel: [<ffffffff810642a8>] worker_thread+0x145/0x226
Jun 20 23:35:27 midori kernel: [<ffffffff81064163>] ? worker_thread+0x0/0x226
Jun 20 23:35:27 midori kernel: [<ffffffff81067501>] kthread+0x82/0x8a
Jun 20 23:35:27 midori kernel: [<ffffffff8100aa64>]
kernel_thread_helper+0x4/0x10
Jun 20 23:35:27 midori kernel: [<ffffffff8106747f>] ? kthread+0x0/0x8a
Jun 20 23:35:27 midori kernel: [<ffffffff8100aa60>] ?
kernel_thread_helper+0x0/0x10
Jun 20 23:35:27 midori kernel: INFO: task jbd2/dm-0-8:1246 blocked for
more than 120 seconds.
..
Jun 20 23:37:41 midori kernel: <1>md/raid:md127: Operation continuing on 8
devices.
..
Jun 20 23:37:45 midori kernel: <1>md/raid:md127: Operation continuing on 7
devices.
[-- Attachment #2: mann_md127.parts2.txt --]
[-- Type: text/plain, Size: 11240 bytes --]
linux-raid@vger.kernel.org
Neil Brown,
I've posted to your webpage (http://neil.brown.name/blog/20090817000931) in the past, so I hope you don't mind too much if I ask you for advice... even if your not overly interested since the array failed during "normal" use and not a conversion or grow.
I have a 10x2TB RAID6 array and I notice three drives have a different "Event id" than the other 7 drives does this imply I'm "out of luck?". *UPDATE* just noticed one of the three drives was a "spare" (why the same event id?)
Do you think the array will just "start up" if I try to assemble it? Minus 2drives? Did the array not "freeze" after the 1st error?
I haven't tried anything yet... other than booting the machine after renaming the mdadm.conf file (I expected this to prevent the array from starting, however, a small 150G array started, maybe I needed to comment out the entries rather than rename the file).
I have 8 ST32000542AS drives hanging off an "AOC-SASLP-MV8" card and 4 others on the motherboard ports (boot+spare) I think the 8 on the raid-card drives went offline. All drives appear to have come back after reboot.
I can provide you with more details, logs or even a "login" if you like.
Note: after the *update* comment (spare) things are looking less dire but any reassurance is appreciated.
Thank you,
-mann
mdadm -Evs
ARRAY /dev/md/127 level=raid6 metadata=1.2 num-devices=10 UUID=1747a894:8c1b4ea6:78d906f1:e0012a25 name=midori:127
spares=1 devices=/dev/sdl1,/dev/sdk1,/dev/sdj1,/dev/sdi1,/dev/sdh1,/dev/sdg1,/dev/sdf1,/dev/sde1,/dev/sdd3,/dev/sdb3,/dev/sdc3
ARRAY /dev/md/128 level=raid0 metadata=1.2 num-devices=6 UUID=b941a4ef:a119f0a7:5b9a19de:066487fd name=midori.gmind.org:128
devices=/dev/sdl2,/dev/sdk2,/dev/sdj2,/dev/sdi2,/dev/sdh2,/dev/sdg2
cat /proc/mdstat
# at time of failure #
Personalities : [raid0] [raid6] [raid5] [raid4]
md128 : active raid0 sdk2[5] sdl2[3] sdi2[2] sdg2[0] sdh2[1] sdj2[4]
154263552 blocks super 1.2 512k chunks
md127 : active raid6 sdk1[8](F) sdi1[3](F) sdl1[7](F) sdf1[4](F) sdg1[6](F) sde1[2](F) sdh1[5](F) sdj1[0](F) sdb3[9] sdd3[11](S) sdc3[10]
15422390272 blocks super 1.2 level 6, 512k chunk, algorithm 2 [10/2] [________UU]
unused devices: <none>
# after reboot #
Personalities : [raid0]
md126 : active raid0 sdl2[3] sdh2[1] sdk2[5] sdj2[4] sdg2[0] sdi2[2]
154263552 blocks super 1.2 512k chunks
md127 : inactive sdf1[4](S) sdh1[5](S) sdb3[9](S) sdi1[3](S) sdj1[0](S) sdd3[11](S) sdl1[7](S) sde1[2](S) sdg1[6](S) sdk1[8](S) sdc3[10](S)
21205788389 blocks super 1.2
unused devices: <none>
/dev/mapper/vg_media-lv_repo01:
Version : 1.2
Creation Time : Sun Oct 3 18:37:02 2010
Raid Level : raid6
Array Size : 15422357504 (14707.91 GiB 15792.49 GB)
Used Dev Size : unknown
Raid Devices : 10
Total Devices : 11
Persistence : Superblock is persistent
Update Time : Tue Jun 21 00:15:45 2011
State : clean, FAILED
Active Devices : 2
Working Devices : 3
Failed Devices : 8
Spare Devices : 1
Layout : left-symmetric
Chunk Size : 512K
Name : midori:127
UUID : 1747a894:8c1b4ea6:78d906f1:e0012a25
Events : 120973
Number Major Minor RaidDevice State
0 0 0 0 removed
1 0 0 1 removed
2 0 0 2 removed
3 0 0 3 removed
4 0 0 4 removed
5 0 0 5 removed
6 0 0 6 removed
7 0 0 7 removed
9 8 19 8 active sync /dev/sdb3
10 8 35 9 active sync /dev/sdc3
0 8 145 - faulty spare /dev/sdj1
2 8 65 - faulty spare /dev/sde1
3 8 129 - faulty spare /dev/sdi1
4 8 81 - faulty spare /dev/sdf1
5 8 113 - faulty spare /dev/sdh1
6 8 97 - faulty spare /dev/sdg1
7 8 177 - faulty spare /dev/sdl1
8 8 161 - faulty spare /dev/sdk1
11 8 51 - spare /dev/sdd3
/dev/sdf1:
Array UUID : 1747a894:8c1b4ea6:78d906f1:e0012a25
Device UUID : 4d6a2158:b7fa56b2:214613af:69af783c
Checksum : 2510e6ed - correct
Events : 120904
Device Role : Active device 4
/dev/sdh1:
Array UUID : 1747a894:8c1b4ea6:78d906f1:e0012a25
Device UUID : b2a48e12:796b2c18:376beed8:74596771
Checksum : a41d6455 - correct
Events : 120904
Device Role : Active device 5
/dev/sdb3:
Array UUID : 1747a894:8c1b4ea6:78d906f1:e0012a25
Device UUID : e3834a2e:f8949e75:b26d1c5b:8631dbd9
Checksum : 7e35341 - correct
Events : 121003
Device Role : Active device 8
/dev/sdi1:
Array UUID : 1747a894:8c1b4ea6:78d906f1:e0012a25
Device UUID : d9b17712:cd167319:c17dcfc3:d847fcd2
Checksum : f1c31a9c - correct
Events : 120904
Device Role : Active device 3
/dev/sdj1:
Array UUID : 1747a894:8c1b4ea6:78d906f1:e0012a25
Device UUID : f1cb78ca:df118e47:57ade846:740e0c47
Checksum : cf0825f5 - correct
Events : 120904
Device Role : Active device 0
/dev/sdd3:
Array UUID : 1747a894:8c1b4ea6:78d906f1:e0012a25
Device UUID : a166f386:a6aa95dc:7f7ea369:3226d7ff
Checksum : fc065128 - correct
Events : 121003
/dev/sdl1:
Array UUID : 1747a894:8c1b4ea6:78d906f1:e0012a25
Device UUID : 7e5d9ed7:13fe2b3e:acbe1b4a:1ab3f660
Checksum : efe959b8 - correct
Events : 120904
Device Role : Active device 1
/dev/sde1:
Array UUID : 1747a894:8c1b4ea6:78d906f1:e0012a25
Device UUID : 3ee69896:cea55b57:229052b4:f5ca02cf
Checksum : a0567380 - correct
Events : 120904
Device Role : Active device 2
/dev/sdg1:
Array UUID : 1747a894:8c1b4ea6:78d906f1:e0012a25
Device UUID : 1035f17d:79452818:33fd5c41:dcab73ab
Checksum : b1f6aff8 - correct
Events : 120904
Device Role : Active device 6
/dev/sdk1:
Array UUID : 1747a894:8c1b4ea6:78d906f1:e0012a25
Device UUID : cafe0241:222eb745:0bf1d0f2:c66f0c09
Checksum : b1a41a1f - correct
Events : 120904
Device Role : Active device 7
/dev/sdc3:
Array UUID : 1747a894:8c1b4ea6:78d906f1:e0012a25
Device UUID : 746265e7:475ba235:dc367ab3:82f482a4
Checksum : a4078448 - correct
Events : 121003
Device Role : Active device 9
Jun 20 23:34:57 midori kernel: ata13: translated ATA stat/err 0x01/04 to SCSI SK/ASC/ASCQ 0xb/00/00
Jun 20 23:34:57 midori kernel: ata13: status=0x01 { Error }
Jun 20 23:34:57 midori kernel: ata13: error=0x04 { DriveStatusError }
Jun 20 23:34:57 midori kernel: sd 6:0:6:0: [sdk] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jun 20 23:34:57 midori kernel: sd 6:0:6:0: [sdk] Sense Key : Aborted Command [current] [descriptor]
Jun 20 23:34:57 midori kernel: Descriptor sense data with sense descriptors (in hex):
Jun 20 23:34:57 midori kernel: 72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00
Jun 20 23:34:57 midori kernel: 00 00 00 56
Jun 20 23:34:57 midori kernel: sd 6:0:6:0: [sdk] Add. Sense: No additional sense information
Jun 20 23:34:57 midori kernel: sd 6:0:6:0: [sdk] CDB: Write(10): 2a 00 a1 3f e0 3f 00 02 00 00
Jun 20 23:34:57 midori kernel: end_request: I/O error, dev sdk, sector 2705317951
Jun 20 23:34:57 midori kernel: md/raid:md127: Disk failure on sdk1, disabling device.
Jun 20 23:34:57 midori kernel: <1>md/raid:md127: Operation continuing on 9 devices.
Jun 20 23:34:57 midori kernel: ata13: translated ATA stat/err 0x01/04 to SCSI SK/ASC/ASCQ 0xb/00/00
Jun 20 23:34:57 midori kernel: ata13: status=0x01 { Error }
Jun 20 23:34:57 midori kernel: ata13: error=0x04 { DriveStatusError }
Jun 20 23:34:57 midori kernel: sd 6:0:6:0: [sdk] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jun 20 23:34:57 midori kernel: sd 6:0:6:0: [sdk] Sense Key : Aborted Command [current] [descriptor]
Jun 20 23:34:57 midori kernel: Descriptor sense data with sense descriptors (in hex):
Jun 20 23:34:57 midori kernel: 72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00
Jun 20 23:34:57 midori kernel: 00 00 00 56
Jun 20 23:34:57 midori kernel: sd 6:0:6:0: [sdk] Add. Sense: No additional sense information
Jun 20 23:34:57 midori kernel: sd 6:0:6:0: [sdk] CDB: Read(10): 28 00 a1 3f de 5f 00 01 e0 00
Jun 20 23:34:57 midori kernel: end_request: I/O error, dev sdk, sector 2705317471
Jun 20 23:35:27 midori kernel: INFO: task kworker/u:7:345 blocked for more than 120 seconds.
Jun 20 23:35:27 midori kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jun 20 23:35:27 midori kernel: kworker/u:7 D 0000000000000000 0 345 2 0x00000000
Jun 20 23:35:27 midori kernel: ffff88003716ba10 0000000000000046 ffff88003965aa00 ffff88003716a010
Jun 20 23:35:27 midori kernel: ffff88003716bfd8 0000000000014940 ffff88003711ae60 ffff88003711b218
Jun 20 23:35:27 midori kernel: ffff88003711b210 0000000000014940 0000000000014940 ffff88003716bfd8
Jun 20 23:35:27 midori kernel: Call Trace:
Jun 20 23:35:27 midori kernel: [<ffffffffa030bb9a>] get_active_stripe+0x2c2/0x660 [raid456]
Jun 20 23:35:27 midori kernel: [<ffffffff81048abb>] ? default_wake_function+0x0/0x14
Jun 20 23:35:27 midori kernel: [<ffffffffa030f2ba>] make_request+0x21e/0x487 [raid456]
Jun 20 23:35:27 midori kernel: [<ffffffff8106799b>] ? autoremove_wake_function+0x0/0x39
Jun 20 23:35:27 midori kernel: [<ffffffff81347c06>] md_make_request+0xd4/0x1dc
Jun 20 23:35:27 midori kernel: [<ffffffff810c8ebf>] ? mempool_alloc_slab+0x15/0x17
Jun 20 23:35:27 midori kernel: [<ffffffff810c8fad>] ? mempool_alloc+0x71/0x12a
Jun 20 23:35:27 midori kernel: [<ffffffff811e3d2c>] generic_make_request+0x2da/0x35e
Jun 20 23:35:27 midori kernel: [<ffffffff813537b1>] __map_bio+0xa2/0xfe
Jun 20 23:35:27 midori kernel: [<ffffffff81354fad>] __split_and_process_bio+0x2a2/0x55e
Jun 20 23:35:27 midori kernel: [<ffffffff8100a60e>] ? apic_timer_interrupt+0xe/0x20
Jun 20 23:35:27 midori kernel: [<ffffffff8135560f>] dm_wq_work+0x151/0x182
Jun 20 23:35:27 midori kernel: [<ffffffff813554be>] ? dm_wq_work+0x0/0x182
Jun 20 23:35:27 midori kernel: [<ffffffff810627c4>] process_one_work+0x1a5/0x2b3
Jun 20 23:35:27 midori kernel: [<ffffffff810642a8>] worker_thread+0x145/0x226
Jun 20 23:35:27 midori kernel: [<ffffffff81064163>] ? worker_thread+0x0/0x226
Jun 20 23:35:27 midori kernel: [<ffffffff81067501>] kthread+0x82/0x8a
Jun 20 23:35:27 midori kernel: [<ffffffff8100aa64>] kernel_thread_helper+0x4/0x10
Jun 20 23:35:27 midori kernel: [<ffffffff8106747f>] ? kthread+0x0/0x8a
Jun 20 23:35:27 midori kernel: [<ffffffff8100aa60>] ? kernel_thread_helper+0x0/0x10
Jun 20 23:35:27 midori kernel: INFO: task jbd2/dm-0-8:1246 blocked for more than 120 seconds.
..
Jun 20 23:37:41 midori kernel: <1>md/raid:md127: Operation continuing on 8 devices.
..
Jun 20 23:37:45 midori kernel: <1>md/raid:md127: Operation continuing on 7 devices.
^ permalink raw reply
* (unknown),
From: Ntai Jerry @ 2011-06-21 22:21 UTC (permalink / raw)
My name is Mr. Jerry Ntai; I am the Head of Operations in Mevas Bank, Hong
Kong. I have a business proposal in the tune of US$25.2m to be transferred
to an offshore account with your assistance if willing. After the
successful transfer, we shall share in ratio of 30% for you and 70% for
me. Should you be interested, please respond to my letter immediately, so
we can commence all arrangements and I will give you more information on
the project and how we would handle it.
You can contact me on my private email: ( j.ntai1100@gmail.com ) and
send me the following information for documentation purpose:
(1) Full name:
(2) Private phone number:
(3) Current residential address:
(4) Occupation:
(5) Age and Sex
I look forward to hearing from you.
Kind Regards.
^ permalink raw reply
* Re: reaid problem at reboot
From: Phil Turmel @ 2011-06-21 21:58 UTC (permalink / raw)
To: william L'Heureux; +Cc: linux-raid
In-Reply-To: <BAY158-w388BBEAFF686EAA222B346C0510@phx.gbl>
Hi William,
On 06/21/2011 04:50 PM, william L'Heureux wrote:
>
> ./lsdrv
> PCI [sata_mv] 02:01.0 SCSI storage controller: Marvell Technology Group Ltd. MV8 8SX6081 8-port SATA II PCI-X Controller (rev 09)
> ââscsi 0:0:0:0 ATA Hitachi HDS72202 {JK1171YAGA977S}
> â ââsda: [8:0] Partitioned (gpt) 1.82t
> â ââsda1: [8:1] MD raid6 (6) 1.82t inactive 'BILLSSHACK:0' {3bcf45ef-da3e-d e81-09a8-d6635b58832d}
> â ââsda2: [8:2] Empty/Unknown 1.00g
> ââscsi 1:0:0:0 ATA WL2000GSA1672 {WOL240094387}
> â ââsdb: [8:16] Partitioned (gpt) 1.82t
> â ââsdb1: [8:17] MD raid6 (6) 1.82t inactive 'billsshack:3' {751fd632-4baf- 7d64-ec26-eec1046592bc}
> â ââsdb2: [8:18] Empty/Unknown 1.00g
> ââscsi 2:x:x:x [Empty]
> ââscsi 3:x:x:x [Empty]
> ââscsi 4:0:0:0 ATA WL2000GSA1672 {WOL240094356}
> â ââsdc: [8:32] Partitioned (gpt) 1.82t
> â ââsdc1: [8:33] MD raid6 (6) 1.82t inactive 'BILLSSHACK:0' {3bcf45ef-da3e- de81-09a8-d6635b58832d}
> â ââsdc2: [8:34] Empty/Unknown 1.00g
> ââscsi 5:0:0:0 ATA WL2000GSA3272C {WOL240146377}
> â ââsdd: [8:48] Partitioned (gpt) 1.82t
> â ââsdd1: [8:49] MD raid6 (6) 1.82t inactive 'BILLSSHACK:0' {3bcf45ef-da3e- de81-09a8-d6635b58832d}
> â ââsdd2: [8:50] Empty/Unknown 1.00g
> ââscsi 6:x:x:x [Empty]
> ââscsi 7:x:x:x [Empty]
> PCI [sata_mv] 03:02.0 SCSI storage controller: Marvell Technology Group Ltd. MV8 8SX6081 8-port SATA II PCI-X Controller (rev 09)
> ââscsi 8:0:0:0 ATA WL2000GSA3272 {WOL240102099}
> â ââsde: [8:64] Partitioned (gpt) 1.82t
> â ââsde1: [8:65] MD raid6 (6) 1.82t inactive 'billsshack:3' {751fd632-4baf- 7d64-ec26-eec1046592bc}
> â ââsde2: [8:66] Empty/Unknown 1.00g
> ââscsi 9:x:x:x [Empty]
> ââscsi 10:0:0:0 ATA Hitachi HDS72202 {JK1171YAGDDUGS}
> â ââsdf: [8:80] Partitioned (gpt) 1.82t
> â ââsdf1: [8:81] MD raid6 (6) 1.82t inactive 'billsshack:3' {751fd632-4baf- 7d64-ec26-eec1046592bc}
> â ââsdf2: [8:82] Empty/Unknown 1.00g
> ââscsi 11:0:0:0 ATA ST32000542AS {6XW1B8WP}
> â ââsdg: [8:96] Partitioned (gpt) 1.82t
> â ââsdg1: [8:97] MD raid6 (6) 1.82t inactive 'billsshack:3' {751fd632-4baf- 7d64-ec26-eec1046592bc}
> â ââsdg2: [8:98] Empty/Unknown 1.00g
> ââscsi 12:0:0:0 ATA WL2000GSA3272 {WOL240102098}
> â ââsdh: [8:112] Partitioned (gpt) 1.82t
> â ââsdh1: [8:113] MD raid6 (6) 1.82t inactive 'BILLSSHACK:0' {3bcf45ef-da3e -de81-09a8-d6635b58832d}
> â ââsdh2: [8:114] Empty/Unknown 1.00g
> ââscsi 13:0:0:0 ATA WDC WD20EADS-00S {WD-WCAVY3323665}
> â ââsdi: [8:128] Partitioned (gpt) 1.82t
> â ââsdi1: [8:129] MD raid6 (6) 1.82t inactive 'BILLSSHACK:0' {3bcf45ef-da3e -de81-09a8-d6635b58832d}
> â ââsdi2: [8:130] Empty/Unknown 1.00g
> ââscsi 14:0:0:0 ATA WDC WD20EADS-00S {WD-WCAVY3356471}
> â ââsdj: [8:144] Partitioned (gpt) 1.82t
> â ââsdj1: [8:145] MD raid6 (6) 1.82t inactive 'BILLSSHACK:0' {3bcf45ef-da3e -de81-09a8-d6635b58832d}
> â ââsdj2: [8:146] Empty/Unknown 1.00g
> ââscsi 15:x:x:x [Empty]
> PCI [ahci] 00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH ) 6 port SATA AHCI Controller (rev 02)
> ââscsi 16:x:x:x [Empty]
> ââscsi 17:x:x:x [Empty]
> ââscsi 18:0:0:0 ATA WDC WD20EADS-00S {WD-WCAVY3286477}
> â ââsdk: [8:160] Partitioned (gpt) 1.82t
> â ââsdk1: [8:161] MD raid6 (6) 1.82t inactive 'billsshack:3' {751fd632-4baf -7d64-ec26-eec1046592bc}
> â ââsdk2: [8:162] Empty/Unknown 1.00g
> ââscsi 19:0:0:0 ATA WDC WD400BD-60LT {WD-WMAME1857443}
> â ââsdl: [8:176] Partitioned (dos) 37.27g
> â ââsdl1: [8:177] Partitioned (dos) 133.32m {617e6b03-6cc1-4974-8acc-19a742 cd06f4}
> â â ââMounted as /dev/sdl1 @ /boot
> â ââsdl2: [8:178] PV LVM2_member 22.00g/37.14g VG vgDeb 37.14g {0ecAby-vT4R -IHpt-5kEK-v1W0-u6AL-bUcFDG}
> â ââVolume Group vgDeb (sdl2) 15.14g free {a6nM6t-LPKY-gMdi-9YP4-t2tv-H qjv-aMgmEa}
> â ââdm-1: [251:1] LV 'root' (reiserfs) 10.00g {f497b9bd-e24f-4d20-9f6 b-282b6493f341}
> â â ââMounted as /dev/mapper/vgDeb-root @ /mnt/debian
> â ââdm-2: [251:2] LV 'rootu' (reiserfs) 10.00g {bc0f350c-4af7-4192-b1 ea-4528101db28e}
> â â ââMounted as /dev/mapper/vgDeb-rootu @ /
> â ââdm-0: [251:0] LV 'swap' (swap) 2.00g {13264e60-a1d1-4bf3-af9f-edd 948212a63}
> ââscsi 20:0:0:0 ATA WDC WD20EADS-00S {WD-WCAVY3271728}
> â ââsdm: [8:192] MD raid6 (4) 1.82t inactive {b52df561-301f-043c-b5a7-b1ab9d93 4878}
> â ââsdm1: [8:193] MD raid6 (6) 1.82t inactive 'billsshack:3' {751fd632-4baf -7d64-ec26-eec1046592bc}
> â ââsdm2: [8:194] MD raid6 (6) 1.00g inactive 'billsshack:2' {cf2450e4-bc7a -9cea-cb5c-cda96f3ec87c}
> ââscsi 21:x:x:x [Empty]
> Other Block Devices
> ââram0: [1:0] Empty/Unknown 64.00m
> ââram1: [1:1] Empty/Unknown 64.00m
> ââram2: [1:2] Empty/Unknown 64.00m
> ââram3: [1:3] Empty/Unknown 64.00m
> ââram4: [1:4] Empty/Unknown 64.00m
> ââram5: [1:5] Empty/Unknown 64.00m
> ââram6: [1:6] Empty/Unknown 64.00m
> ââram7: [1:7] Empty/Unknown 64.00m
> ââram8: [1:8] Empty/Unknown 64.00m
> ââram9: [1:9] Empty/Unknown 64.00m
> ââram10: [1:10] Empty/Unknown 64.00m
> ââram11: [1:11] Empty/Unknown 64.00m
> ââram12: [1:12] Empty/Unknown 64.00m
> ââram13: [1:13] Empty/Unknown 64.00m
> ââram14: [1:14] Empty/Unknown 64.00m
> ââram15: [1:15] Empty/Unknown 64.00m
OK. We know the basic layout. (I think I'm going to have to give up the fancy line-drawing characters. Very few emails get them right...)
> mdadm --detail /dev/md0 /dev/md1
> /dev/md0:
> Version : 1.2
> Creation Time : Tue Jun 21 11:23:46 2011
> Raid Level : raid6
> Array Size : 7809854976 (7448.06 GiB 7997.29 GB)
> Used Dev Size : 1952463744 (1862.01 GiB 1999.32 GB)
> Raid Devices : 6
> Total Devices : 6
> Persistence : Superblock is persistent
>
> Update Time : Tue Jun 21 11:23:46 2011
> State : clean
> Active Devices : 6
> Working Devices : 6
> Failed Devices : 0
> Spare Devices : 0
>
> Layout : left-symmetric
> Chunk Size : 128K
>
> Name : BILLSSHACK:0 (local to host BILLSSHACK)
> UUID : 3bcf45ef:da3ede81:09a8d663:5b58832d
> Events : 0
>
> Number Major Minor RaidDevice State
> 0 8 1 0 active sync /dev/sda1
> 1 8 33 1 active sync /dev/sdc1
> 2 8 49 2 active sync /dev/sdd1
> 3 8 113 3 active sync /dev/sdh1
> 4 8 129 4 active sync /dev/sdi1
> 5 8 145 5 active sync /dev/sdj1
> /dev/md1:
> Version : 1.2
> Creation Time : Tue Jun 15 09:59:08 2010
> Raid Level : raid6
> Array Size : 7809855488 (7448.06 GiB 7997.29 GB)
> Used Dev Size : 1952463872 (1862.01 GiB 1999.32 GB)
> Raid Devices : 6
> Total Devices : 6
> Persistence : Superblock is persistent
>
> Intent Bitmap : Internal
>
> Update Time : Tue Jun 14 20:58:11 2011
> State : active
> Active Devices : 6
> Working Devices : 6
> Failed Devices : 0
> Spare Devices : 0
>
> Layout : left-symmetric
> Chunk Size : 128K
>
> Name : billsshack:3
> UUID : 751fd632:4baf7d64:ec26eec1:046592bc
> Events : 235082
>
> Number Major Minor RaidDevice State
> 0 8 161 0 active sync /dev/sdk1
> 1 8 17 1 active sync /dev/sdb1
> 8 8 193 2 active sync /dev/sdm1
> 5 8 81 3 active sync /dev/sdf1
> 6 8 65 4 active sync /dev/sde1
> 7 8 97 5 active sync /dev/sdg1
It is not immediately clear from this, or from your first email, which of your two raid6 arrays is messed up.
> mdadm --examine /dev/sd[abcdefghijkm]1
> /dev/sda1:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x0
> Array UUID : 3bcf45ef:da3ede81:09a8d663:5b58832d
> Name : BILLSSHACK:0 (local to host BILLSSHACK)
> Creation Time : Tue Jun 21 11:23:46 2011
> Raid Level : raid6
> Raid Devices : 6
>
> Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
> Array Size : 15619709952 (7448.06 GiB 7997.29 GB)
> Used Dev Size : 3904927488 (1862.01 GiB 1999.32 GB)
> Data Offset : 2048 sectors
> Super Offset : 8 sectors
> State : clean
> Device UUID : b6569293:759c2fbe:d52f346f:2ea85306
>
> Update Time : Tue Jun 21 16:35:23 2011
> Checksum : 9d90c200 - correct
> Events : 2
>
> Layout : left-symmetric
> Chunk Size : 128K
>
> Device Role : Active device 0
> Array State : AAAAAA ('A' == active, '.' == missing)
2048 sectors offset. This is important.
> /dev/sdb1:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x1
> Array UUID : 751fd632:4baf7d64:ec26eec1:046592bc
> Name : billsshack:3
> Creation Time : Tue Jun 15 09:59:08 2010
> Raid Level : raid6
> Raid Devices : 6
>
> Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
> Array Size : 15619710976 (7448.06 GiB 7997.29 GB)
> Used Dev Size : 3904927744 (1862.01 GiB 1999.32 GB)
> Data Offset : 2048 sectors
> Super Offset : 8 sectors
> State : clean
> Device UUID : 0b6a5d24:bff1c401:259c054b:ca7ccc7f
>
> Internal Bitmap : 2 sectors from superblock
> Update Time : Tue Jun 21 16:35:23 2011
> Checksum : bed09424 - correct
> Events : 235082
>
> Layout : left-symmetric
> Chunk Size : 128K
>
> Device Role : Active device 1
> Array State : AAAAAA ('A' == active, '.' == missing)
> /dev/sdc1:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x0
> Array UUID : 3bcf45ef:da3ede81:09a8d663:5b58832d
> Name : BILLSSHACK:0 (local to host BILLSSHACK)
> Creation Time : Tue Jun 21 11:23:46 2011
> Raid Level : raid6
> Raid Devices : 6
>
> Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
> Array Size : 15619709952 (7448.06 GiB 7997.29 GB)
> Used Dev Size : 3904927488 (1862.01 GiB 1999.32 GB)
> Data Offset : 2048 sectors
> Super Offset : 8 sectors
> State : clean
> Device UUID : 298ee23a:4968978c:0557d189:1c45ff55
>
> Update Time : Tue Jun 21 16:35:23 2011
> Checksum : 7d918966 - correct
> Events : 2
>
> Layout : left-symmetric
> Chunk Size : 128K
>
> Device Role : Active device 1
> Array State : AAAAAA ('A' == active, '.' == missing)
> /dev/sdd1:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x0
> Array UUID : 3bcf45ef:da3ede81:09a8d663:5b58832d
> Name : BILLSSHACK:0 (local to host BILLSSHACK)
> Creation Time : Tue Jun 21 11:23:46 2011
> Raid Level : raid6
> Raid Devices : 6
>
> Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
> Array Size : 15619709952 (7448.06 GiB 7997.29 GB)
> Used Dev Size : 3904927488 (1862.01 GiB 1999.32 GB)
> Data Offset : 2048 sectors
> Super Offset : 8 sectors
> State : clean
> Device UUID : 2b8ef61c:d3d59200:659d4367:573a992d
>
> Update Time : Tue Jun 21 16:35:23 2011
> Checksum : 88ad328d - correct
> Events : 2
>
> Layout : left-symmetric
> Chunk Size : 128K
>
> Device Role : Active device 2
> Array State : AAAAAA ('A' == active, '.' == missing)
> /dev/sde1:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x1
> Array UUID : 751fd632:4baf7d64:ec26eec1:046592bc
> Name : billsshack:3
> Creation Time : Tue Jun 15 09:59:08 2010
> Raid Level : raid6
> Raid Devices : 6
>
> Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
> Array Size : 15619710976 (7448.06 GiB 7997.29 GB)
> Used Dev Size : 3904927744 (1862.01 GiB 1999.32 GB)
> Data Offset : 2048 sectors
> Super Offset : 8 sectors
> State : clean
> Device UUID : 1de7b73d:73ff1f80:c0903159:87fc8287
>
> Internal Bitmap : 2 sectors from superblock
> Update Time : Tue Jun 21 16:35:23 2011
> Checksum : 6c689348 - correct
> Events : 235082
>
> Layout : left-symmetric
> Chunk Size : 128K
>
> Device Role : Active device 4
> Array State : AAAAAA ('A' == active, '.' == missing)
> /dev/sdf1:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x1
> Array UUID : 751fd632:4baf7d64:ec26eec1:046592bc
> Name : billsshack:3
> Creation Time : Tue Jun 15 09:59:08 2010
> Raid Level : raid6
> Raid Devices : 6
>
> Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
> Array Size : 15619710976 (7448.06 GiB 7997.29 GB)
> Used Dev Size : 3904927744 (1862.01 GiB 1999.32 GB)
> Data Offset : 2048 sectors
> Super Offset : 8 sectors
> State : clean
> Device UUID : 3247b37b:aa741693:0d58ccb6:b814a5d1
>
> Internal Bitmap : 2 sectors from superblock
> Update Time : Tue Jun 21 16:35:23 2011
> Checksum : 65174812 - correct
> Events : 235082
>
> Layout : left-symmetric
> Chunk Size : 128K
>
> Device Role : Active device 3
> Array State : AAAAAA ('A' == active, '.' == missing)
> /dev/sdg1:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x1
> Array UUID : 751fd632:4baf7d64:ec26eec1:046592bc
> Name : billsshack:3
> Creation Time : Tue Jun 15 09:59:08 2010
> Raid Level : raid6
> Raid Devices : 6
>
> Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
> Array Size : 15619710976 (7448.06 GiB 7997.29 GB)
> Used Dev Size : 3904927744 (1862.01 GiB 1999.32 GB)
> Data Offset : 2048 sectors
> Super Offset : 8 sectors
> State : clean
> Device UUID : 8483b8f7:8c3302c6:9403a3e9:3c3a094c
>
> Internal Bitmap : 2 sectors from superblock
> Update Time : Tue Jun 21 16:35:23 2011
> Checksum : c1431453 - correct
> Events : 235082
>
> Layout : left-symmetric
> Chunk Size : 128K
>
> Device Role : Active device 5
> Array State : AAAAAA ('A' == active, '.' == missing)
> /dev/sdh1:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x0
> Array UUID : 3bcf45ef:da3ede81:09a8d663:5b58832d
> Name : BILLSSHACK:0 (local to host BILLSSHACK)
> Creation Time : Tue Jun 21 11:23:46 2011
> Raid Level : raid6
> Raid Devices : 6
>
> Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
> Array Size : 15619709952 (7448.06 GiB 7997.29 GB)
> Used Dev Size : 3904927488 (1862.01 GiB 1999.32 GB)
> Data Offset : 2048 sectors
> Super Offset : 8 sectors
> State : clean
> Device UUID : 1abe5069:570c484e:2199572d:cd0d641f
>
> Update Time : Tue Jun 21 16:35:23 2011
> Checksum : da9b6833 - correct
> Events : 2
>
> Layout : left-symmetric
> Chunk Size : 128K
>
> Device Role : Active device 3
> Array State : AAAAAA ('A' == active, '.' == missing)
> /dev/sdi1:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x0
> Array UUID : 3bcf45ef:da3ede81:09a8d663:5b58832d
> Name : BILLSSHACK:0 (local to host BILLSSHACK)
> Creation Time : Tue Jun 21 11:23:46 2011
> Raid Level : raid6
> Raid Devices : 6
>
> Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
> Array Size : 15619709952 (7448.06 GiB 7997.29 GB)
> Used Dev Size : 3904927488 (1862.01 GiB 1999.32 GB)
> Data Offset : 2048 sectors
> Super Offset : 8 sectors
> State : clean
> Device UUID : 083fa0cc:798c09bb:febe5adf:f99eb7b8
>
> Update Time : Tue Jun 21 16:35:23 2011
> Checksum : f603204f - correct
> Events : 2
>
> Layout : left-symmetric
> Chunk Size : 128K
>
> Device Role : Active device 4
> Array State : AAAAAA ('A' == active, '.' == missing)
> /dev/sdj1:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x0
> Array UUID : 3bcf45ef:da3ede81:09a8d663:5b58832d
> Name : BILLSSHACK:0 (local to host BILLSSHACK)
> Creation Time : Tue Jun 21 11:23:46 2011
> Raid Level : raid6
> Raid Devices : 6
>
> Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
> Array Size : 15619709952 (7448.06 GiB 7997.29 GB)
> Used Dev Size : 3904927488 (1862.01 GiB 1999.32 GB)
> Data Offset : 2048 sectors
> Super Offset : 8 sectors
> State : clean
> Device UUID : b91a18a4:8aba8cf8:bf046c8f:f683cf16
>
> Update Time : Tue Jun 21 16:35:23 2011
> Checksum : 192754d0 - correct
> Events : 2
>
> Layout : left-symmetric
> Chunk Size : 128K
>
> Device Role : Active device 5
> Array State : AAAAAA ('A' == active, '.' == missing)
> /dev/sdk1:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x1
> Array UUID : 751fd632:4baf7d64:ec26eec1:046592bc
> Name : billsshack:3
> Creation Time : Tue Jun 15 09:59:08 2010
> Raid Level : raid6
> Raid Devices : 6
>
> Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
> Array Size : 15619710976 (7448.06 GiB 7997.29 GB)
> Used Dev Size : 3904927744 (1862.01 GiB 1999.32 GB)
> Data Offset : 2048 sectors
> Super Offset : 8 sectors
> State : clean
> Device UUID : 77b91aac:68eed1cc:e2404d60:f5962abc
>
> Internal Bitmap : 2 sectors from superblock
> Update Time : Tue Jun 21 16:35:23 2011
> Checksum : 63409f22 - correct
> Events : 235082
>
> Layout : left-symmetric
> Chunk Size : 128K
>
> Device Role : Active device 0
> Array State : AAAAAA ('A' == active, '.' == missing)
> /dev/sdm1:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x1
> Array UUID : 751fd632:4baf7d64:ec26eec1:046592bc
> Name : billsshack:3
> Creation Time : Tue Jun 15 09:59:08 2010
> Raid Level : raid6
> Raid Devices : 6
>
> Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
> Array Size : 15619710976 (7448.06 GiB 7997.29 GB)
> Used Dev Size : 3904927744 (1862.01 GiB 1999.32 GB)
> Data Offset : 2048 sectors
> Super Offset : 8 sectors
> State : clean
> Device UUID : 9b5a6d24:38202032:c40fc666:1f2570d7
>
> Internal Bitmap : 2 sectors from superblock
> Update Time : Tue Jun 21 16:35:23 2011
> Checksum : 629fcf29 - correct
> Events : 235082
>
> Layout : left-symmetric
> Chunk Size : 128K
>
> Device Role : Active device 2
> Array State : AAAAAA ('A' == active, '.' == missing)
They all have a 2048 sector offset. This is good. It means your good array and your bad array were both created with a fairly recent copy of mdadm.
> cat /etc/lvm/backup/*
> # Generated by LVM2 version 2.02.66(2) (2010-05-20): Sat May 21 09:40:02 2011
>
> contents = "Text Format Volume Group"
> version = 1
>
> description = "Created *after* executing 'vgcfgbackup'"
>
> creation_host = "BILLSSHACK" # Linux BILLSSHACK 2.6.35-28-generic-pae #49-Ubuntu SMP Tue Mar 1 14:58:06 UTC 2011 i686
> creation_time = 1305985202 # Sat May 21 09:40:02 2011
>
> vgDeb {
> id = "a6nM6t-LPKY-gMdi-9YP4-t2tv-Hqjv-aMgmEa"
> seqno = 10
> status = ["RESIZEABLE", "READ", "WRITE"]
> flags = []
> extent_size = 8192 # 4 Megabytes
> max_lv = 0
> max_pv = 0
>
> physical_volumes {
>
> pv0 {
> id = "0ecAby-vT4R-IHpt-5kEK-v1W0-u6AL-bUcFDG"
> device = "/dev/sdl2" # Hint only
>
> status = ["ALLOCATABLE"]
> flags = []
> dev_size = 77883120 # 37.1376 Gigabytes
> pe_start = 384
> pe_count = 9507 # 37.1367 Gigabytes
> }
> }
>
> logical_volumes {
>
> swap {
> id = "ywPLVh-84xx-UvPV-fUaI-PPgU-ZiTw-j6rs07"
> status = ["READ", "WRITE", "VISIBLE"]
> flags = []
> segment_count = 1
>
> segment1 {
> start_extent = 0
> extent_count = 512 # 2 Gigabytes
>
> type = "striped"
> stripe_count = 1 # linear
>
> stripes = [
> "pv0", 0
> ]
> }
> }
>
> root {
> id = "x0wMox-eWu2-EmDh-V0Ix-47Zl-iqVc-fTYjVB"
> status = ["READ", "WRITE", "VISIBLE"]
> flags = []
> segment_count = 1
>
> segment1 {
> start_extent = 0
> extent_count = 2560 # 10 Gigabytes
>
> type = "striped"
> stripe_count = 1 # linear
>
> stripes = [
> "pv0", 512
> ]
> }
> }
>
> rootu {
> id = "IFNTXp-4DBN-jjtc-PrCE-Mxs5-68FH-vY5QWK"
> status = ["READ", "WRITE", "VISIBLE"]
> flags = []
> segment_count = 1
>
> segment1 {
> start_extent = 0
> extent_count = 2560 # 10 Gigabytes
>
> type = "striped"
> stripe_count = 1 # linear
>
> stripes = [
> "pv0", 5632
> ]
> }
> }
> }
> }
We won't need the above. That's your system group.
> # Generated by LVM2 version 2.02.66(2) (2010-05-20): Sat May 21 09:40:02 2011
>
> contents = "Text Format Volume Group"
> version = 1
>
> description = "Created *after* executing 'vgcfgbackup'"
>
> creation_host = "BILLSSHACK" # Linux BILLSSHACK 2.6.35-28-generic-pae #49-Ubuntu SMP Tue Mar 1 14:58:06 UTC 2011 i686
> creation_time = 1305985202 # Sat May 21 09:40:02 2011
>
> vgRAID60 {
> id = "RUodpI-jXin-DEjs-fS3R-4hjA-hQ4l-41dAaJ"
> seqno = 58
> status = ["RESIZEABLE", "READ", "WRITE"]
> flags = []
> extent_size = 8192 # 4 Megabytes
> max_lv = 0
> max_pv = 0
>
> physical_volumes {
>
> pv0 {
> id = "V5c1yI-XD3D-FXlB-VDYd-tUfo-eIUC-hXQfVW"
> device = "/dev/md0" # Hint only
>
> status = ["ALLOCATABLE"]
> flags = []
> dev_size = 15619710464 # 7.27349 Terabytes
> pe_start = 512
> pe_count = 1906702 # 7.27349 Terabytes
> }
>
> pv1 {
> id = "XRg0sr-C21F-4v2f-9FzZ-JSQr-JZe2-Tbexqf"
> device = "/dev/md1" # Hint only
>
> status = ["ALLOCATABLE"]
> flags = []
> dev_size = 15619710464 # 7.27349 Terabytes
> pe_start = 512
> pe_count = 1906702 # 7.27349 Terabytes
> }
> }
We can go hunting for these ids. They'll certainly show up on the first disk in each raid. They might also show up in the 5th disk in each raid, if by chance the other data chunks in the stripe are zeros. Please show:
for x in /dev/sd[abcdefghijkm] ; do echo "**** $x ****" ; dd if=$x skip=2056 count=2 2>/dev/null |strings ; done
> logical_volumes {
>
> data0 {
> id = "Odw7bi-10cB-8SSX-Y4BL-wqs6-4qWT-3AHaYL"
> status = ["READ", "WRITE", "VISIBLE"]
> flags = []
> segment_count = 1
>
> segment1 {
> start_extent = 0
> extent_count = 3670016 # 14 Terabytes
>
> type = "striped"
> stripe_count = 2
> stripe_size = 128 # 64 Kilobytes
>
> stripes = [
> "pv0", 0,
> "pv1", 0
> ]
> }
> }
> }
> }
Hmmm. Striped LVM on top of raid6. Trying to get better performance? With this striping, getting the data back requires 100% success. You won't get half of your data. You might get all of it, or you might get none of it.
> Again, i am not a raid pro. those commands i can understand, if anywhere i make a mistake about a mdadm concept, please tell me.
>
> Nevertheless, thanks for you help
You are welcome.
Phil
--
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
^ permalink raw reply
* RE: reaid problem at reboot
From: william L'Heureux @ 2011-06-21 20:50 UTC (permalink / raw)
To: philip; +Cc: linux-raid
In-Reply-To: <4E00FC8A.1050908@turmel.org>
----------------------------------------
> Date: Tue, 21 Jun 2011 16:18:18 -0400
> From: philip@turmel.org
> To: wil_c_will@hotmail.com
> CC: linux-raid@vger.kernel.org
> Subject: Re: reaid problem at reboot
>
> Hi William,
>
> On 06/21/2011 09:14 AM, william L'Heureux wrote:
> > Hi,
> >
> > before we start, please note that im not a pro at mdadm or lvm, and dont now the full terminology neither the full how it works.
>
> That's OK. We'll help as we can.
>
> > 1 week ago, 1 of my raid6 went wrong. it didnt have any superblock anymore. I know all the drives that belongs to that raid but
> > i
> > dont know the right order of the drives. I tried a python script with
> > assemble and permutation all combination possible. it then checks
> > the
> > header and do a e2fsck -n to check errors. Everytime i run the script i
> > get several and different results on each run. Some say that
> > the
> > order of the drives doesnt matter, i agree but withotuh superblock its
> > another story. I got another raid6 which is fine and on top of those
> > 2
> > raid6, there is a lvm. if you have any question or output you want to
> > see, please tell me and i will provide further informations as soon as i
> > can
> > if you dont understand me, i apologize, im trying to be better at english everyday.
>
> First, an overview of what working: Please show the output of "lsdrv".
>
> http://github.com/pturmel/lsdrv
>
> Then, some more detail: Please show "mdadm --detail /dev/md0 /dev/md1" and "mdadm --examine /dev/sd[abcdefghijkm]1"
>
> Finally, please show "cat /etc/lvm/backup/*"
>
> Phil
> --
> 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
> Date: Tue, 21 Jun 2011 16:18:18 -0400
> From: philip@turmel.org
> To: wil_c_will@hotmail.com
> CC: linux-raid@vger.kernel.org
> Subject: Re: reaid problem at reboot
>
> Hi William,
>
> On 06/21/2011 09:14 AM, william L'Heureux wrote:
> > Hi,
> >
> > before we start, please note that im not a pro at mdadm or lvm, and dont now the full terminology neither the full how it works.
>
> That's OK. We'll help as we can.
>
> > 1 week ago, 1 of my raid6 went wrong. it didnt have any superblock anymore. I know all the drives that belongs to that raid but
> > i
> > dont know the right order of the drives. I tried a python script with
> > assemble and permutation all combination possible. it then checks
> > the
> > header and do a e2fsck -n to check errors. Everytime i run the script i
> > get several and different results on each run. Some say that
> > the
> > order of the drives doesnt matter, i agree but withotuh superblock its
> > another story. I got another raid6 which is fine and on top of those
> > 2
> > raid6, there is a lvm. if you have any question or output you want to
> > see, please tell me and i will provide further informations as soon as i
> > can
> > if you dont understand me, i apologize, im trying to be better at english everyday.
>
> First, an overview of what working: Please show the output of "lsdrv".
>
> http://github.com/pturmel/lsdrv
>
> Then, some more detail: Please show "mdadm --detail /dev/md0 /dev/md1" and "mdadm --examine /dev/sd[abcdefghijkm]1"
>
> Finally, please show "cat /etc/lvm/backup/*"
>
> Phil
> --
> 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
./lsdrv
PCI [sata_mv] 02:01.0 SCSI storage controller: Marvell Technology Group Ltd. MV8 8SX6081 8-port SATA II PCI-X Controller (rev 09)
ââscsi 0:0:0:0 ATA Hitachi HDS72202 {JK1171YAGA977S}
â ââsda: [8:0] Partitioned (gpt) 1.82t
â ââsda1: [8:1] MD raid6 (6) 1.82t inactive 'BILLSSHACK:0' {3bcf45ef-da3e-d e81-09a8-d6635b58832d}
â ââsda2: [8:2] Empty/Unknown 1.00g
ââscsi 1:0:0:0 ATA WL2000GSA1672 {WOL240094387}
â ââsdb: [8:16] Partitioned (gpt) 1.82t
â ââsdb1: [8:17] MD raid6 (6) 1.82t inactive 'billsshack:3' {751fd632-4baf- 7d64-ec26-eec1046592bc}
â ââsdb2: [8:18] Empty/Unknown 1.00g
ââscsi 2:x:x:x [Empty]
ââscsi 3:x:x:x [Empty]
ââscsi 4:0:0:0 ATA WL2000GSA1672 {WOL240094356}
â ââsdc: [8:32] Partitioned (gpt) 1.82t
â ââsdc1: [8:33] MD raid6 (6) 1.82t inactive 'BILLSSHACK:0' {3bcf45ef-da3e- de81-09a8-d6635b58832d}
â ââsdc2: [8:34] Empty/Unknown 1.00g
ââscsi 5:0:0:0 ATA WL2000GSA3272C {WOL240146377}
â ââsdd: [8:48] Partitioned (gpt) 1.82t
â ââsdd1: [8:49] MD raid6 (6) 1.82t inactive 'BILLSSHACK:0' {3bcf45ef-da3e- de81-09a8-d6635b58832d}
â ââsdd2: [8:50] Empty/Unknown 1.00g
ââscsi 6:x:x:x [Empty]
ââscsi 7:x:x:x [Empty]
PCI [sata_mv] 03:02.0 SCSI storage controller: Marvell Technology Group Ltd. MV8 8SX6081 8-port SATA II PCI-X Controller (rev 09)
ââscsi 8:0:0:0 ATA WL2000GSA3272 {WOL240102099}
â ââsde: [8:64] Partitioned (gpt) 1.82t
â ââsde1: [8:65] MD raid6 (6) 1.82t inactive 'billsshack:3' {751fd632-4baf- 7d64-ec26-eec1046592bc}
â ââsde2: [8:66] Empty/Unknown 1.00g
ââscsi 9:x:x:x [Empty]
ââscsi 10:0:0:0 ATA Hitachi HDS72202 {JK1171YAGDDUGS}
â ââsdf: [8:80] Partitioned (gpt) 1.82t
â ââsdf1: [8:81] MD raid6 (6) 1.82t inactive 'billsshack:3' {751fd632-4baf- 7d64-ec26-eec1046592bc}
â ââsdf2: [8:82] Empty/Unknown 1.00g
ââscsi 11:0:0:0 ATA ST32000542AS {6XW1B8WP}
â ââsdg: [8:96] Partitioned (gpt) 1.82t
â ââsdg1: [8:97] MD raid6 (6) 1.82t inactive 'billsshack:3' {751fd632-4baf- 7d64-ec26-eec1046592bc}
â ââsdg2: [8:98] Empty/Unknown 1.00g
ââscsi 12:0:0:0 ATA WL2000GSA3272 {WOL240102098}
â ââsdh: [8:112] Partitioned (gpt) 1.82t
â ââsdh1: [8:113] MD raid6 (6) 1.82t inactive 'BILLSSHACK:0' {3bcf45ef-da3e -de81-09a8-d6635b58832d}
â ââsdh2: [8:114] Empty/Unknown 1.00g
ââscsi 13:0:0:0 ATA WDC WD20EADS-00S {WD-WCAVY3323665}
â ââsdi: [8:128] Partitioned (gpt) 1.82t
â ââsdi1: [8:129] MD raid6 (6) 1.82t inactive 'BILLSSHACK:0' {3bcf45ef-da3e -de81-09a8-d6635b58832d}
â ââsdi2: [8:130] Empty/Unknown 1.00g
ââscsi 14:0:0:0 ATA WDC WD20EADS-00S {WD-WCAVY3356471}
â ââsdj: [8:144] Partitioned (gpt) 1.82t
â ââsdj1: [8:145] MD raid6 (6) 1.82t inactive 'BILLSSHACK:0' {3bcf45ef-da3e -de81-09a8-d6635b58832d}
â ââsdj2: [8:146] Empty/Unknown 1.00g
ââscsi 15:x:x:x [Empty]
PCI [ahci] 00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH ) 6 port SATA AHCI Controller (rev 02)
ââscsi 16:x:x:x [Empty]
ââscsi 17:x:x:x [Empty]
ââscsi 18:0:0:0 ATA WDC WD20EADS-00S {WD-WCAVY3286477}
â ââsdk: [8:160] Partitioned (gpt) 1.82t
â ââsdk1: [8:161] MD raid6 (6) 1.82t inactive 'billsshack:3' {751fd632-4baf -7d64-ec26-eec1046592bc}
â ââsdk2: [8:162] Empty/Unknown 1.00g
ââscsi 19:0:0:0 ATA WDC WD400BD-60LT {WD-WMAME1857443}
â ââsdl: [8:176] Partitioned (dos) 37.27g
â ââsdl1: [8:177] Partitioned (dos) 133.32m {617e6b03-6cc1-4974-8acc-19a742 cd06f4}
â â ââMounted as /dev/sdl1 @ /boot
â ââsdl2: [8:178] PV LVM2_member 22.00g/37.14g VG vgDeb 37.14g {0ecAby-vT4R -IHpt-5kEK-v1W0-u6AL-bUcFDG}
â ââVolume Group vgDeb (sdl2) 15.14g free {a6nM6t-LPKY-gMdi-9YP4-t2tv-H qjv-aMgmEa}
â ââdm-1: [251:1] LV 'root' (reiserfs) 10.00g {f497b9bd-e24f-4d20-9f6 b-282b6493f341}
â â ââMounted as /dev/mapper/vgDeb-root @ /mnt/debian
â ââdm-2: [251:2] LV 'rootu' (reiserfs) 10.00g {bc0f350c-4af7-4192-b1 ea-4528101db28e}
â â ââMounted as /dev/mapper/vgDeb-rootu @ /
â ââdm-0: [251:0] LV 'swap' (swap) 2.00g {13264e60-a1d1-4bf3-af9f-edd 948212a63}
ââscsi 20:0:0:0 ATA WDC WD20EADS-00S {WD-WCAVY3271728}
â ââsdm: [8:192] MD raid6 (4) 1.82t inactive {b52df561-301f-043c-b5a7-b1ab9d93 4878}
â ââsdm1: [8:193] MD raid6 (6) 1.82t inactive 'billsshack:3' {751fd632-4baf -7d64-ec26-eec1046592bc}
â ââsdm2: [8:194] MD raid6 (6) 1.00g inactive 'billsshack:2' {cf2450e4-bc7a -9cea-cb5c-cda96f3ec87c}
ââscsi 21:x:x:x [Empty]
Other Block Devices
ââram0: [1:0] Empty/Unknown 64.00m
ââram1: [1:1] Empty/Unknown 64.00m
ââram2: [1:2] Empty/Unknown 64.00m
ââram3: [1:3] Empty/Unknown 64.00m
ââram4: [1:4] Empty/Unknown 64.00m
ââram5: [1:5] Empty/Unknown 64.00m
ââram6: [1:6] Empty/Unknown 64.00m
ââram7: [1:7] Empty/Unknown 64.00m
ââram8: [1:8] Empty/Unknown 64.00m
ââram9: [1:9] Empty/Unknown 64.00m
ââram10: [1:10] Empty/Unknown 64.00m
ââram11: [1:11] Empty/Unknown 64.00m
ââram12: [1:12] Empty/Unknown 64.00m
ââram13: [1:13] Empty/Unknown 64.00m
ââram14: [1:14] Empty/Unknown 64.00m
ââram15: [1:15] Empty/Unknown 64.00m
mdadm --detail /dev/md0 /dev/md1
/dev/md0:
Version : 1.2
Creation Time : Tue Jun 21 11:23:46 2011
Raid Level : raid6
Array Size : 7809854976 (7448.06 GiB 7997.29 GB)
Used Dev Size : 1952463744 (1862.01 GiB 1999.32 GB)
Raid Devices : 6
Total Devices : 6
Persistence : Superblock is persistent
Update Time : Tue Jun 21 11:23:46 2011
State : clean
Active Devices : 6
Working Devices : 6
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 128K
Name : BILLSSHACK:0 (local to host BILLSSHACK)
UUID : 3bcf45ef:da3ede81:09a8d663:5b58832d
Events : 0
Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
1 8 33 1 active sync /dev/sdc1
2 8 49 2 active sync /dev/sdd1
3 8 113 3 active sync /dev/sdh1
4 8 129 4 active sync /dev/sdi1
5 8 145 5 active sync /dev/sdj1
/dev/md1:
Version : 1.2
Creation Time : Tue Jun 15 09:59:08 2010
Raid Level : raid6
Array Size : 7809855488 (7448.06 GiB 7997.29 GB)
Used Dev Size : 1952463872 (1862.01 GiB 1999.32 GB)
Raid Devices : 6
Total Devices : 6
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Tue Jun 14 20:58:11 2011
State : active
Active Devices : 6
Working Devices : 6
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 128K
Name : billsshack:3
UUID : 751fd632:4baf7d64:ec26eec1:046592bc
Events : 235082
Number Major Minor RaidDevice State
0 8 161 0 active sync /dev/sdk1
1 8 17 1 active sync /dev/sdb1
8 8 193 2 active sync /dev/sdm1
5 8 81 3 active sync /dev/sdf1
6 8 65 4 active sync /dev/sde1
7 8 97 5 active sync /dev/sdg1
mdadm --examine /dev/sd[abcdefghijkm]1
/dev/sda1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 3bcf45ef:da3ede81:09a8d663:5b58832d
Name : BILLSSHACK:0 (local to host BILLSSHACK)
Creation Time : Tue Jun 21 11:23:46 2011
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
Array Size : 15619709952 (7448.06 GiB 7997.29 GB)
Used Dev Size : 3904927488 (1862.01 GiB 1999.32 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : b6569293:759c2fbe:d52f346f:2ea85306
Update Time : Tue Jun 21 16:35:23 2011
Checksum : 9d90c200 - correct
Events : 2
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 0
Array State : AAAAAA ('A' == active, '.' == missing)
/dev/sdb1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 751fd632:4baf7d64:ec26eec1:046592bc
Name : billsshack:3
Creation Time : Tue Jun 15 09:59:08 2010
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
Array Size : 15619710976 (7448.06 GiB 7997.29 GB)
Used Dev Size : 3904927744 (1862.01 GiB 1999.32 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 0b6a5d24:bff1c401:259c054b:ca7ccc7f
Internal Bitmap : 2 sectors from superblock
Update Time : Tue Jun 21 16:35:23 2011
Checksum : bed09424 - correct
Events : 235082
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 1
Array State : AAAAAA ('A' == active, '.' == missing)
/dev/sdc1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 3bcf45ef:da3ede81:09a8d663:5b58832d
Name : BILLSSHACK:0 (local to host BILLSSHACK)
Creation Time : Tue Jun 21 11:23:46 2011
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
Array Size : 15619709952 (7448.06 GiB 7997.29 GB)
Used Dev Size : 3904927488 (1862.01 GiB 1999.32 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 298ee23a:4968978c:0557d189:1c45ff55
Update Time : Tue Jun 21 16:35:23 2011
Checksum : 7d918966 - correct
Events : 2
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 1
Array State : AAAAAA ('A' == active, '.' == missing)
/dev/sdd1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 3bcf45ef:da3ede81:09a8d663:5b58832d
Name : BILLSSHACK:0 (local to host BILLSSHACK)
Creation Time : Tue Jun 21 11:23:46 2011
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
Array Size : 15619709952 (7448.06 GiB 7997.29 GB)
Used Dev Size : 3904927488 (1862.01 GiB 1999.32 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 2b8ef61c:d3d59200:659d4367:573a992d
Update Time : Tue Jun 21 16:35:23 2011
Checksum : 88ad328d - correct
Events : 2
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 2
Array State : AAAAAA ('A' == active, '.' == missing)
/dev/sde1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 751fd632:4baf7d64:ec26eec1:046592bc
Name : billsshack:3
Creation Time : Tue Jun 15 09:59:08 2010
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
Array Size : 15619710976 (7448.06 GiB 7997.29 GB)
Used Dev Size : 3904927744 (1862.01 GiB 1999.32 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 1de7b73d:73ff1f80:c0903159:87fc8287
Internal Bitmap : 2 sectors from superblock
Update Time : Tue Jun 21 16:35:23 2011
Checksum : 6c689348 - correct
Events : 235082
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 4
Array State : AAAAAA ('A' == active, '.' == missing)
/dev/sdf1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 751fd632:4baf7d64:ec26eec1:046592bc
Name : billsshack:3
Creation Time : Tue Jun 15 09:59:08 2010
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
Array Size : 15619710976 (7448.06 GiB 7997.29 GB)
Used Dev Size : 3904927744 (1862.01 GiB 1999.32 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 3247b37b:aa741693:0d58ccb6:b814a5d1
Internal Bitmap : 2 sectors from superblock
Update Time : Tue Jun 21 16:35:23 2011
Checksum : 65174812 - correct
Events : 235082
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 3
Array State : AAAAAA ('A' == active, '.' == missing)
/dev/sdg1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 751fd632:4baf7d64:ec26eec1:046592bc
Name : billsshack:3
Creation Time : Tue Jun 15 09:59:08 2010
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
Array Size : 15619710976 (7448.06 GiB 7997.29 GB)
Used Dev Size : 3904927744 (1862.01 GiB 1999.32 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 8483b8f7:8c3302c6:9403a3e9:3c3a094c
Internal Bitmap : 2 sectors from superblock
Update Time : Tue Jun 21 16:35:23 2011
Checksum : c1431453 - correct
Events : 235082
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 5
Array State : AAAAAA ('A' == active, '.' == missing)
/dev/sdh1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 3bcf45ef:da3ede81:09a8d663:5b58832d
Name : BILLSSHACK:0 (local to host BILLSSHACK)
Creation Time : Tue Jun 21 11:23:46 2011
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
Array Size : 15619709952 (7448.06 GiB 7997.29 GB)
Used Dev Size : 3904927488 (1862.01 GiB 1999.32 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 1abe5069:570c484e:2199572d:cd0d641f
Update Time : Tue Jun 21 16:35:23 2011
Checksum : da9b6833 - correct
Events : 2
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 3
Array State : AAAAAA ('A' == active, '.' == missing)
/dev/sdi1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 3bcf45ef:da3ede81:09a8d663:5b58832d
Name : BILLSSHACK:0 (local to host BILLSSHACK)
Creation Time : Tue Jun 21 11:23:46 2011
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
Array Size : 15619709952 (7448.06 GiB 7997.29 GB)
Used Dev Size : 3904927488 (1862.01 GiB 1999.32 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 083fa0cc:798c09bb:febe5adf:f99eb7b8
Update Time : Tue Jun 21 16:35:23 2011
Checksum : f603204f - correct
Events : 2
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 4
Array State : AAAAAA ('A' == active, '.' == missing)
/dev/sdj1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 3bcf45ef:da3ede81:09a8d663:5b58832d
Name : BILLSSHACK:0 (local to host BILLSSHACK)
Creation Time : Tue Jun 21 11:23:46 2011
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
Array Size : 15619709952 (7448.06 GiB 7997.29 GB)
Used Dev Size : 3904927488 (1862.01 GiB 1999.32 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : b91a18a4:8aba8cf8:bf046c8f:f683cf16
Update Time : Tue Jun 21 16:35:23 2011
Checksum : 192754d0 - correct
Events : 2
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 5
Array State : AAAAAA ('A' == active, '.' == missing)
/dev/sdk1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 751fd632:4baf7d64:ec26eec1:046592bc
Name : billsshack:3
Creation Time : Tue Jun 15 09:59:08 2010
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
Array Size : 15619710976 (7448.06 GiB 7997.29 GB)
Used Dev Size : 3904927744 (1862.01 GiB 1999.32 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 77b91aac:68eed1cc:e2404d60:f5962abc
Internal Bitmap : 2 sectors from superblock
Update Time : Tue Jun 21 16:35:23 2011
Checksum : 63409f22 - correct
Events : 235082
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 0
Array State : AAAAAA ('A' == active, '.' == missing)
/dev/sdm1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 751fd632:4baf7d64:ec26eec1:046592bc
Name : billsshack:3
Creation Time : Tue Jun 15 09:59:08 2010
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
Array Size : 15619710976 (7448.06 GiB 7997.29 GB)
Used Dev Size : 3904927744 (1862.01 GiB 1999.32 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 9b5a6d24:38202032:c40fc666:1f2570d7
Internal Bitmap : 2 sectors from superblock
Update Time : Tue Jun 21 16:35:23 2011
Checksum : 629fcf29 - correct
Events : 235082
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 2
Array State : AAAAAA ('A' == active, '.' == missing)
cat /etc/lvm/backup/*
# Generated by LVM2 version 2.02.66(2) (2010-05-20): Sat May 21 09:40:02 2011
contents = "Text Format Volume Group"
version = 1
description = "Created *after* executing 'vgcfgbackup'"
creation_host = "BILLSSHACK" # Linux BILLSSHACK 2.6.35-28-generic-pae #49-Ubuntu SMP Tue Mar 1 14:58:06 UTC 2011 i686
creation_time = 1305985202 # Sat May 21 09:40:02 2011
vgDeb {
id = "a6nM6t-LPKY-gMdi-9YP4-t2tv-Hqjv-aMgmEa"
seqno = 10
status = ["RESIZEABLE", "READ", "WRITE"]
flags = []
extent_size = 8192 # 4 Megabytes
max_lv = 0
max_pv = 0
physical_volumes {
pv0 {
id = "0ecAby-vT4R-IHpt-5kEK-v1W0-u6AL-bUcFDG"
device = "/dev/sdl2" # Hint only
status = ["ALLOCATABLE"]
flags = []
dev_size = 77883120 # 37.1376 Gigabytes
pe_start = 384
pe_count = 9507 # 37.1367 Gigabytes
}
}
logical_volumes {
swap {
id = "ywPLVh-84xx-UvPV-fUaI-PPgU-ZiTw-j6rs07"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 1
segment1 {
start_extent = 0
extent_count = 512 # 2 Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 0
]
}
}
root {
id = "x0wMox-eWu2-EmDh-V0Ix-47Zl-iqVc-fTYjVB"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 1
segment1 {
start_extent = 0
extent_count = 2560 # 10 Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 512
]
}
}
rootu {
id = "IFNTXp-4DBN-jjtc-PrCE-Mxs5-68FH-vY5QWK"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 1
segment1 {
start_extent = 0
extent_count = 2560 # 10 Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 5632
]
}
}
}
}
# Generated by LVM2 version 2.02.66(2) (2010-05-20): Sat May 21 09:40:02 2011
contents = "Text Format Volume Group"
version = 1
description = "Created *after* executing 'vgcfgbackup'"
creation_host = "BILLSSHACK" # Linux BILLSSHACK 2.6.35-28-generic-pae #49-Ubuntu SMP Tue Mar 1 14:58:06 UTC 2011 i686
creation_time = 1305985202 # Sat May 21 09:40:02 2011
vgRAID60 {
id = "RUodpI-jXin-DEjs-fS3R-4hjA-hQ4l-41dAaJ"
seqno = 58
status = ["RESIZEABLE", "READ", "WRITE"]
flags = []
extent_size = 8192 # 4 Megabytes
max_lv = 0
max_pv = 0
physical_volumes {
pv0 {
id = "V5c1yI-XD3D-FXlB-VDYd-tUfo-eIUC-hXQfVW"
device = "/dev/md0" # Hint only
status = ["ALLOCATABLE"]
flags = []
dev_size = 15619710464 # 7.27349 Terabytes
pe_start = 512
pe_count = 1906702 # 7.27349 Terabytes
}
pv1 {
id = "XRg0sr-C21F-4v2f-9FzZ-JSQr-JZe2-Tbexqf"
device = "/dev/md1" # Hint only
status = ["ALLOCATABLE"]
flags = []
dev_size = 15619710464 # 7.27349 Terabytes
pe_start = 512
pe_count = 1906702 # 7.27349 Terabytes
}
}
logical_volumes {
data0 {
id = "Odw7bi-10cB-8SSX-Y4BL-wqs6-4qWT-3AHaYL"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 1
segment1 {
start_extent = 0
extent_count = 3670016 # 14 Terabytes
type = "striped"
stripe_count = 2
stripe_size = 128 # 64 Kilobytes
stripes = [
"pv0", 0,
"pv1", 0
]
}
}
}
}
Again, i am not a raid pro. those commands i can understand, if anywhere i make a mistake about a mdadm concept, please tell me.
Nevertheless, thanks for you help
William
--
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
^ permalink raw reply
* RE: reaid problem at reboot
From: william L'Heureux @ 2011-06-21 20:39 UTC (permalink / raw)
To: philip; +Cc: linux-raid
In-Reply-To: <4E00FC8A.1050908@turmel.org>
> Date: Tue, 21 Jun 2011 16:18:18 -0400
> From: philip@turmel.org
> To: wil_c_will@hotmail.com
> CC: linux-raid@vger.kernel.org
> Subject: Re: reaid problem at reboot
>
> Hi William,
>
> On 06/21/2011 09:14 AM, william L'Heureux wrote:
> > Hi,
> >
> > before we start, please note that im not a pro at mdadm or lvm, and dont now the full terminology neither the full how it works.
>
> That's OK. We'll help as we can.
>
> > 1 week ago, 1 of my raid6 went wrong. it didnt have any superblock anymore. I know all the drives that belongs to that raid but
> > i
> > dont know the right order of the drives. I tried a python script with
> > assemble and permutation all combination possible. it then checks
> > the
> > header and do a e2fsck -n to check errors. Everytime i run the script i
> > get several and different results on each run. Some say that
> > the
> > order of the drives doesnt matter, i agree but withotuh superblock its
> > another story. I got another raid6 which is fine and on top of those
> > 2
> > raid6, there is a lvm. if you have any question or output you want to
> > see, please tell me and i will provide further informations as soon as i
> > can
> > if you dont understand me, i apologize, im trying to be better at english everyday.
>
> First, an overview of what working: Please show the output of "lsdrv".
>
> http://github.com/pturmel/lsdrv
>
> Then, some more detail: Please show "mdadm --detail /dev/md0 /dev/md1" and "mdadm --examine /dev/sd[abcdefghijkm]1"
>
> Finally, please show "cat /etc/lvm/backup/*"
>
> Phil
> --
> 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
sorry about lsdvr but im getting an error:
./lsdrv
File "./lsdrv", line 26
def __init__(self, **entries):
^
IndentationError: expected an indented block
mdadm --detail /dev/md0 /dev/md1
/dev/md0:
Version : 1.2
Creation Time : Tue Jun 21 11:23:46 2011
Raid Level : raid6
Array Size : 7809854976 (7448.06 GiB 7997.29 GB)
Used Dev Size : 1952463744 (1862.01 GiB 1999.32 GB)
Raid Devices : 6
Total Devices : 6
Persistence : Superblock is persistent
Update Time : Tue Jun 21 11:23:46 2011
State : clean
Active Devices : 6
Working Devices : 6
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 128K
Name : BILLSSHACK:0 (local to host BILLSSHACK)
UUID : 3bcf45ef:da3ede81:09a8d663:5b58832d
Events : 0
Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
1 8 33 1 active sync /dev/sdc1
2 8 49 2 active sync /dev/sdd1
3 8 113 3 active sync /dev/sdh1
4 8 129 4 active sync /dev/sdi1
5 8 145 5 active sync /dev/sdj1
/dev/md1:
Version : 1.2
Creation Time : Tue Jun 15 09:59:08 2010
Raid Level : raid6
Array Size : 7809855488 (7448.06 GiB 7997.29 GB)
Used Dev Size : 1952463872 (1862.01 GiB 1999.32 GB)
Raid Devices : 6
Total Devices : 6
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Tue Jun 14 20:58:11 2011
State : active
Active Devices : 6
Working Devices : 6
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 128K
Name : billsshack:3
UUID : 751fd632:4baf7d64:ec26eec1:046592bc
Events : 235082
Number Major Minor RaidDevice State
0 8 161 0 active sync /dev/sdk1
1 8 17 1 active sync /dev/sdb1
8 8 193 2 active sync /dev/sdm1
5 8 81 3 active sync /dev/sdf1
6 8 65 4 active sync /dev/sde1
7 8 97 5 active sync /dev/sdg1
mdadm --examine /dev/sd[abcdefghijkm]1
/dev/sda1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 3bcf45ef:da3ede81:09a8d663:5b58832d
Name : BILLSSHACK:0 (local to host BILLSSHACK)
Creation Time : Tue Jun 21 11:23:46 2011
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
Array Size : 15619709952 (7448.06 GiB 7997.29 GB)
Used Dev Size : 3904927488 (1862.01 GiB 1999.32 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : b6569293:759c2fbe:d52f346f:2ea85306
Update Time : Tue Jun 21 16:35:23 2011
Checksum : 9d90c200 - correct
Events : 2
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 0
Array State : AAAAAA ('A' == active, '.' == missing)
/dev/sdb1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 751fd632:4baf7d64:ec26eec1:046592bc
Name : billsshack:3
Creation Time : Tue Jun 15 09:59:08 2010
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
Array Size : 15619710976 (7448.06 GiB 7997.29 GB)
Used Dev Size : 3904927744 (1862.01 GiB 1999.32 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 0b6a5d24:bff1c401:259c054b:ca7ccc7f
Internal Bitmap : 2 sectors from superblock
Update Time : Tue Jun 21 16:35:23 2011
Checksum : bed09424 - correct
Events : 235082
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 1
Array State : AAAAAA ('A' == active, '.' == missing)
/dev/sdc1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 3bcf45ef:da3ede81:09a8d663:5b58832d
Name : BILLSSHACK:0 (local to host BILLSSHACK)
Creation Time : Tue Jun 21 11:23:46 2011
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
Array Size : 15619709952 (7448.06 GiB 7997.29 GB)
Used Dev Size : 3904927488 (1862.01 GiB 1999.32 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 298ee23a:4968978c:0557d189:1c45ff55
Update Time : Tue Jun 21 16:35:23 2011
Checksum : 7d918966 - correct
Events : 2
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 1
Array State : AAAAAA ('A' == active, '.' == missing)
/dev/sdd1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 3bcf45ef:da3ede81:09a8d663:5b58832d
Name : BILLSSHACK:0 (local to host BILLSSHACK)
Creation Time : Tue Jun 21 11:23:46 2011
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
Array Size : 15619709952 (7448.06 GiB 7997.29 GB)
Used Dev Size : 3904927488 (1862.01 GiB 1999.32 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 2b8ef61c:d3d59200:659d4367:573a992d
Update Time : Tue Jun 21 16:35:23 2011
Checksum : 88ad328d - correct
Events : 2
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 2
Array State : AAAAAA ('A' == active, '.' == missing)
/dev/sde1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 751fd632:4baf7d64:ec26eec1:046592bc
Name : billsshack:3
Creation Time : Tue Jun 15 09:59:08 2010
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
Array Size : 15619710976 (7448.06 GiB 7997.29 GB)
Used Dev Size : 3904927744 (1862.01 GiB 1999.32 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 1de7b73d:73ff1f80:c0903159:87fc8287
Internal Bitmap : 2 sectors from superblock
Update Time : Tue Jun 21 16:35:23 2011
Checksum : 6c689348 - correct
Events : 235082
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 4
Array State : AAAAAA ('A' == active, '.' == missing)
/dev/sdf1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 751fd632:4baf7d64:ec26eec1:046592bc
Name : billsshack:3
Creation Time : Tue Jun 15 09:59:08 2010
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
Array Size : 15619710976 (7448.06 GiB 7997.29 GB)
Used Dev Size : 3904927744 (1862.01 GiB 1999.32 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 3247b37b:aa741693:0d58ccb6:b814a5d1
Internal Bitmap : 2 sectors from superblock
Update Time : Tue Jun 21 16:35:23 2011
Checksum : 65174812 - correct
Events : 235082
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 3
Array State : AAAAAA ('A' == active, '.' == missing)
/dev/sdg1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 751fd632:4baf7d64:ec26eec1:046592bc
Name : billsshack:3
Creation Time : Tue Jun 15 09:59:08 2010
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
Array Size : 15619710976 (7448.06 GiB 7997.29 GB)
Used Dev Size : 3904927744 (1862.01 GiB 1999.32 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 8483b8f7:8c3302c6:9403a3e9:3c3a094c
Internal Bitmap : 2 sectors from superblock
Update Time : Tue Jun 21 16:35:23 2011
Checksum : c1431453 - correct
Events : 235082
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 5
Array State : AAAAAA ('A' == active, '.' == missing)
/dev/sdh1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 3bcf45ef:da3ede81:09a8d663:5b58832d
Name : BILLSSHACK:0 (local to host BILLSSHACK)
Creation Time : Tue Jun 21 11:23:46 2011
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
Array Size : 15619709952 (7448.06 GiB 7997.29 GB)
Used Dev Size : 3904927488 (1862.01 GiB 1999.32 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 1abe5069:570c484e:2199572d:cd0d641f
Update Time : Tue Jun 21 16:35:23 2011
Checksum : da9b6833 - correct
Events : 2
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 3
Array State : AAAAAA ('A' == active, '.' == missing)
/dev/sdi1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 3bcf45ef:da3ede81:09a8d663:5b58832d
Name : BILLSSHACK:0 (local to host BILLSSHACK)
Creation Time : Tue Jun 21 11:23:46 2011
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
Array Size : 15619709952 (7448.06 GiB 7997.29 GB)
Used Dev Size : 3904927488 (1862.01 GiB 1999.32 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 083fa0cc:798c09bb:febe5adf:f99eb7b8
Update Time : Tue Jun 21 16:35:23 2011
Checksum : f603204f - correct
Events : 2
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 4
Array State : AAAAAA ('A' == active, '.' == missing)
/dev/sdj1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 3bcf45ef:da3ede81:09a8d663:5b58832d
Name : BILLSSHACK:0 (local to host BILLSSHACK)
Creation Time : Tue Jun 21 11:23:46 2011
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
Array Size : 15619709952 (7448.06 GiB 7997.29 GB)
Used Dev Size : 3904927488 (1862.01 GiB 1999.32 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : b91a18a4:8aba8cf8:bf046c8f:f683cf16
Update Time : Tue Jun 21 16:35:23 2011
Checksum : 192754d0 - correct
Events : 2
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 5
Array State : AAAAAA ('A' == active, '.' == missing)
/dev/sdk1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 751fd632:4baf7d64:ec26eec1:046592bc
Name : billsshack:3
Creation Time : Tue Jun 15 09:59:08 2010
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
Array Size : 15619710976 (7448.06 GiB 7997.29 GB)
Used Dev Size : 3904927744 (1862.01 GiB 1999.32 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 77b91aac:68eed1cc:e2404d60:f5962abc
Internal Bitmap : 2 sectors from superblock
Update Time : Tue Jun 21 16:35:23 2011
Checksum : 63409f22 - correct
Events : 235082
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 0
Array State : AAAAAA ('A' == active, '.' == missing)
/dev/sdm1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 751fd632:4baf7d64:ec26eec1:046592bc
Name : billsshack:3
Creation Time : Tue Jun 15 09:59:08 2010
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3904927887 (1862.01 GiB 1999.32 GB)
Array Size : 15619710976 (7448.06 GiB 7997.29 GB)
Used Dev Size : 3904927744 (1862.01 GiB 1999.32 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 9b5a6d24:38202032:c40fc666:1f2570d7
Internal Bitmap : 2 sectors from superblock
Update Time : Tue Jun 21 16:35:23 2011
Checksum : 629fcf29 - correct
Events : 235082
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 2
Array State : AAAAAA ('A' == active, '.' == missing)
cat /etc/lvm/backup/*
# Generated by LVM2 version 2.02.66(2) (2010-05-20): Sat May 21 09:40:02 2011
contents = "Text Format Volume Group"
version = 1
description = "Created *after* executing 'vgcfgbackup'"
creation_host = "BILLSSHACK" # Linux BILLSSHACK 2.6.35-28-generic-pae #49-Ubuntu SMP Tue Mar 1 14:58:06 UTC 2011 i686
creation_time = 1305985202 # Sat May 21 09:40:02 2011
vgDeb {
id = "a6nM6t-LPKY-gMdi-9YP4-t2tv-Hqjv-aMgmEa"
seqno = 10
status = ["RESIZEABLE", "READ", "WRITE"]
flags = []
extent_size = 8192 # 4 Megabytes
max_lv = 0
max_pv = 0
physical_volumes {
pv0 {
id = "0ecAby-vT4R-IHpt-5kEK-v1W0-u6AL-bUcFDG"
device = "/dev/sdl2" # Hint only
status = ["ALLOCATABLE"]
flags = []
dev_size = 77883120 # 37.1376 Gigabytes
pe_start = 384
pe_count = 9507 # 37.1367 Gigabytes
}
}
logical_volumes {
swap {
id = "ywPLVh-84xx-UvPV-fUaI-PPgU-ZiTw-j6rs07"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 1
segment1 {
start_extent = 0
extent_count = 512 # 2 Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 0
]
}
}
root {
id = "x0wMox-eWu2-EmDh-V0Ix-47Zl-iqVc-fTYjVB"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 1
segment1 {
start_extent = 0
extent_count = 2560 # 10 Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 512
]
}
}
rootu {
id = "IFNTXp-4DBN-jjtc-PrCE-Mxs5-68FH-vY5QWK"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 1
segment1 {
start_extent = 0
extent_count = 2560 # 10 Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 5632
]
}
}
}
}
# Generated by LVM2 version 2.02.66(2) (2010-05-20): Sat May 21 09:40:02 2011
contents = "Text Format Volume Group"
version = 1
description = "Created *after* executing 'vgcfgbackup'"
creation_host = "BILLSSHACK" # Linux BILLSSHACK 2.6.35-28-generic-pae #49-Ubuntu SMP Tue Mar 1 14:58:06 UTC 2011 i686
creation_time = 1305985202 # Sat May 21 09:40:02 2011
vgRAID60 {
id = "RUodpI-jXin-DEjs-fS3R-4hjA-hQ4l-41dAaJ"
seqno = 58
status = ["RESIZEABLE", "READ", "WRITE"]
flags = []
extent_size = 8192 # 4 Megabytes
max_lv = 0
max_pv = 0
physical_volumes {
pv0 {
id = "V5c1yI-XD3D-FXlB-VDYd-tUfo-eIUC-hXQfVW"
device = "/dev/md0" # Hint only
status = ["ALLOCATABLE"]
flags = []
dev_size = 15619710464 # 7.27349 Terabytes
pe_start = 512
pe_count = 1906702 # 7.27349 Terabytes
}
pv1 {
id = "XRg0sr-C21F-4v2f-9FzZ-JSQr-JZe2-Tbexqf"
device = "/dev/md1" # Hint only
status = ["ALLOCATABLE"]
flags = []
dev_size = 15619710464 # 7.27349 Terabytes
pe_start = 512
pe_count = 1906702 # 7.27349 Terabytes
}
}
logical_volumes {
data0 {
id = "Odw7bi-10cB-8SSX-Y4BL-wqs6-4qWT-3AHaYL"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 1
segment1 {
start_extent = 0
extent_count = 3670016 # 14 Terabytes
type = "striped"
stripe_count = 2
stripe_size = 128 # 64 Kilobytes
stripes = [
"pv0", 0,
"pv1", 0
]
}
}
}
}
Again, i am not a raid pro. those commands i can understand, if anywhere i make a mistake about a mdadm concept, please tell me.
Nevertheless, thanks for you help
William
--
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
^ permalink raw reply
* Re: reaid problem at reboot
From: Phil Turmel @ 2011-06-21 20:18 UTC (permalink / raw)
To: william L'Heureux; +Cc: linux-raid
In-Reply-To: <BAY158-W207004CCDC35695F84D5B4C0510@phx.gbl>
Hi William,
On 06/21/2011 09:14 AM, william L'Heureux wrote:
> Hi,
>
> before we start, please note that im not a pro at mdadm or lvm, and dont now the full terminology neither the full how it works.
That's OK. We'll help as we can.
> 1 week ago, 1 of my raid6 went wrong. it didnt have any superblock anymore. I know all the drives that belongs to that raid but
> i
> dont know the right order of the drives. I tried a python script with
> assemble and permutation all combination possible. it then checks
> the
> header and do a e2fsck -n to check errors. Everytime i run the script i
> get several and different results on each run. Some say that
> the
> order of the drives doesnt matter, i agree but withotuh superblock its
> another story. I got another raid6 which is fine and on top of those
> 2
> raid6, there is a lvm. if you have any question or output you want to
> see, please tell me and i will provide further informations as soon as i
> can
> if you dont understand me, i apologize, im trying to be better at english everyday.
First, an overview of what working: Please show the output of "lsdrv".
http://github.com/pturmel/lsdrv
Then, some more detail: Please show "mdadm --detail /dev/md0 /dev/md1" and "mdadm --examine /dev/sd[abcdefghijkm]1"
Finally, please show "cat /etc/lvm/backup/*"
Phil
^ permalink raw reply
* Looking for the best way to do this
From: maurice @ 2011-06-21 18:13 UTC (permalink / raw)
To: linux-raid
Good day, and thanks in advance for any ideas and advice.
I am working on a server.
The server is normally in a remote location, not outside accessible by
network,
and there is no easy method to do backups on it.
It is running Fedora 14
It has 2 hard drives at present, and there are 5 partitions on each.
From this we have 3 RAID1 md devices.
These are for /boot, /data and /
I wish to add a 3rd disk, for enhancing the safety of the data.
There is no space to add a 4th disk.
Things I thought of doing include:
Add 3rd disk to make a 3 disk RAID1
Make a RAID10, missing one disk.
Which do you think is the better means to enhance data safety / chances
of surviving a hardware problem?
One of the above, or an other configuration?
And, assuming I want to preserve the existing data, what is the best way
to do this?
--
Cheers,
Maurice Hilarius
eMail: /mhilarius@gmail.com/
^ permalink raw reply
* [PATCH 4/4] .gitignore: ignore mdadm.8 file
From: Namhyung Kim @ 2011-06-21 16:19 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <1308673145-8151-1-git-send-email-namhyung@gmail.com>
mdadm.8 is auto-generated from mdadm.8.in, so ignore it.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
---
.gitignore | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index 2503bd8..7200741 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,6 +2,7 @@
/*.man
/*-stamp
/mdadm
+/mdadm.8
/mdadm.udeb
/mdmon
/swap_super
--
1.7.5.2
^ permalink raw reply related
* [PATCH 3/4] mdadm.8: fix possible typos
From: Namhyung Kim @ 2011-06-21 16:19 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <1308673145-8151-1-git-send-email-namhyung@gmail.com>
Fix random typos and add a few of missing words/macros.
Also update RAID website URL as it is not accessible anymore.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
---
mdadm.8.in | 21 +++++++++++----------
1 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/mdadm.8.in b/mdadm.8.in
index d56cd98..5eee54a 100644
--- a/mdadm.8.in
+++ b/mdadm.8.in
@@ -1496,7 +1496,7 @@ the first device given is the md device.
In the second usage example, all devices listed are treated as md
devices and assembly is attempted.
In the third (where no devices are listed) all md devices that are
-listed in the configuration file are assembled. If not arrays are
+listed in the configuration file are assembled. If no arrays are
described by the configuration file, then any arrays that
can be found on unused devices will be assembled.
@@ -1605,7 +1605,7 @@ and no devices are listed,
will first attempt to assemble all the arrays listed in the config
file.
-In no array at listed in the config (other than those marked
+If no arrays are listed in the config (other than those marked
.BR <ignore> )
it will look through the available devices for possible arrays and
will try to assemble anything that it finds. Arrays which are tagged
@@ -2205,11 +2205,11 @@ change the "size" attribute for RAID1, RAID4, RAID5 and RAID6.
.IP \(bu 4
increase or decrease the "raid\-devices" attribute of RAID0, RAID1, RAID4,
RAID5, and RAID6.
-.IP \bu 4
+.IP \(bu 4
change the chunk-size and layout of RAID0, RAID4, RAID5 and RAID6.
-.IP \bu 4
+.IP \(bu 4
convert between RAID1 and RAID5, between RAID5 and RAID6, between
-RAID0, RAID5, and RAID5, and between RAID0 and RAID10 (in the near-2 mode).
+RAID0, RAID4, and RAID5, and between RAID0 and RAID10 (in the near-2 mode).
.IP \(bu 4
add a write-intent bitmap to any array which supports these bitmaps, or
remove a write-intent bitmap from such an array.
@@ -2255,7 +2255,7 @@ space to start being used. If the size is increased in this way, a
are synchronised.
Note that when an array changes size, any filesystem that may be
-stored in the array will not automatically grow for shrink to use or
+stored in the array will not automatically grow or shrink to use or
vacate the space. The
filesystem will need to be explicitly told to use the extra space
after growing, or to reduce its size
@@ -2264,7 +2264,7 @@ to shrinking the array.
Also the size of an array cannot be changed while it has an active
bitmap. If an array has a bitmap, it must be removed before the size
-can be changed. Once the change it complete a new bitmap can be created.
+can be changed. Once the change is complete a new bitmap can be created.
.SS RAID\-DEVICES CHANGES
@@ -2440,7 +2440,7 @@ must match one of the names or patterns in a
line.
.IP +
-Does the device have a valid md superblock. If a specific metadata
+Does the device have a valid md superblock? If a specific metadata
version is request with
.B \-\-metadata
or
@@ -2472,6 +2472,7 @@ is not able to positively identify the array as belonging to the
current host, the device will be rejected.
..
+.PP
.I mdadm
keeps a list of arrays that it has partially assembled in
.B /var/run/mdadm/map
@@ -2644,7 +2645,7 @@ can be started.
Any devices which are components of /dev/md4 will be marked as faulty
and then remove from the array.
-.B " mdadm --grow /dev/md4 --level=6 --backup-file=/root/backup-md4
+.B " mdadm --grow /dev/md4 --level=6 --backup-file=/root/backup-md4"
.br
The array
.B /dev/md4
@@ -2792,7 +2793,7 @@ configuration file at all.
For further information on mdadm usage, MD and the various levels of
RAID, see:
.IP
-.B http://linux\-raid.osdl.org/
+.B http://raid.wiki.kernel.org/
.PP
(based upon Jakob \(/Ostergaard's Software\-RAID.HOWTO)
.\".PP
--
1.7.5.2
^ permalink raw reply related
* [PATCH 2/4] mdadm.8: move description of --add under Grow mode
From: Namhyung Kim @ 2011-06-21 16:19 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <1308673145-8151-1-git-send-email-namhyung@gmail.com>
It is supposed to be under Grow mode. Since Create/Build/Grow modes
use common options and '-a' is already used for '--auto' in Create/
Build modes, describe it to avoid confusion.
---
mdadm.8.in | 49 +++++++++++++++++++++++++++----------------------
1 files changed, 27 insertions(+), 22 deletions(-)
diff --git a/mdadm.8.in b/mdadm.8.in
index 44accc0..d56cd98 100644
--- a/mdadm.8.in
+++ b/mdadm.8.in
@@ -811,6 +811,11 @@ number, and there is no entry in /dev for that number and with a
non-standard name. Names that are not in 'standard' format are only
allowed in "/dev/md/".
+This is meaningful with
+.B \-\-create
+or
+.BR \-\-build .
+
.ig XX
.\".TP
.\".BR \-\-symlink = no
@@ -835,6 +840,28 @@ allowed in "/dev/md/".
.\"
.XX
+.TP
+.BR \-a ", " "\-\-add"
+This option can be used in Grow mode in two cases.
+
+If the target array is a Linear array, then
+.B \-\-add
+can be used to add one or more devices to the array. They
+are simply catenated on to the end of the array. Once added, the
+devices cannot be removed.
+
+If the
+.B \-\-raid\-disks
+option is being used to increase the number of devices in an array,
+then
+.B \-\-add
+can be used to add some extra devices to be included in the array.
+In most cases this is not needed as the extra devices can be added as
+spares first, and then the number of raid-disks can be changed.
+However for RAID0, it is not possible to add spares. So to increase
+the number of devices in a RAID0, it is necessary to set the new
+number of devices, and to add the new devices, in the same command.
+
.SH For assemble:
.TP
@@ -912,28 +939,6 @@ not as reliable as you would like.
See this option under Create and Build options.
.TP
-.BR \-a ", " "\-\-add"
-This option can be used in Grow mode in two cases.
-
-If the target array is a Linear array, then
-.B \-\-add
-can be used to add one or more devices to the array. They
-are simply catenated on to the end of the array. Once added, the
-devices cannot be removed.
-
-If the
-.B \-\-raid\-disks
-option is being used to increase the number of devices in an array,
-then
-.B \-\-add
-can be used to add some extra devices to be included in the array.
-In most cases this is not needed as the extra devices can be added as
-spares first, and then the number of raid-disks can be changed.
-However for RAID0, it is not possible to add spares. So to increase
-the number of devices in a RAID0, it is necessary to set the new
-number of devices, and to add the new devices, in the same command.
-
-.TP
.BR \-b ", " \-\-bitmap=
Specify the bitmap file that was given when the array was created. If
an array has an
--
1.7.5.2
^ permalink raw reply related
* [PATCH 1/4] mdadm.8: change linux version 2.6.40 -> 3.0
From: Namhyung Kim @ 2011-06-21 16:19 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
---
Grow.c | 2 +-
mdadm.8.in | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Grow.c b/Grow.c
index 6e31b94..a4092b5 100644
--- a/Grow.c
+++ b/Grow.c
@@ -1494,7 +1494,7 @@ int Grow_reshape(char *devname, int fd, int quiet, char *backup_file,
goto release;
}
if (assume_clean) {
- /* This will fail on kernels newer than 2.6.40 unless
+ /* This will fail on kernels newer than 3.0 unless
* a backport has been arranged.
*/
if (sra == NULL ||
diff --git a/mdadm.8.in b/mdadm.8.in
index d2d7ef2..44accc0 100644
--- a/mdadm.8.in
+++ b/mdadm.8.in
@@ -706,7 +706,7 @@ facts the operator knows.
When an array is resized to a larger size with
.B "\-\-grow \-\-size="
the new space is normally resynced in that same way that the whole
-array is resynced at creation. From Linux version 2.6.40,
+array is resynced at creation. From Linux version 3.0,
.B \-\-assume\-clean
can be used with that command to avoid the automatic resync.
--
1.7.5.2
^ permalink raw reply related
* Re: Which Disks can fail?
From: Jonathan Tripathy @ 2011-06-21 15:31 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <20110621214225.5f65ece0@notabene.brown>
On 21/06/2011 12:42, NeilBrown wrote:
> On Tue, 21 Jun 2011 11:56:41 +0100 Jonathan Tripathy<jonnyt@abpni.co.uk>
> wrote:
>
>> On 21/06/2011 11:45, NeilBrown wrote:
>>> On Tue, 21 Jun 2011 11:24:20 +0100 Jonathan Tripathy<jonnyt@abpni.co.uk>
>>> wrote:
>>>
>>>> Hi Everyone,
>>>>
>>>> Use md's "single process" RAID10 with the standard near layout (which is
>>>> apperently the same as RAID1+0 in industry), which 2 drives could fail
>>>> without loosing the array?
>>>>
>>>> This is what I have:
>>>>
>>>> Number Major Minor RaidDevice State
>>>> 0 8 5 0 active sync /dev/sda5
>>>> 1 8 21 1 active sync /dev/sdb5
>>>> 2 8 37 2 active sync /dev/sdc5
>>>> 3 8 53 3 active sync /dev/sdd5
>>>>
>>>> Thanks
>>>> --
>>>> 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
>>> Run
>>>
>>> man 4 md
>>>
>>> search for "RAID10"
>>>
>>> read what you find, and if it doesn't make sense, ask again.
>>> If it does make sense, post your answer and feel free to ask for
>>> confirmation.
>>>
>>>
>>> NeilBrown
>> Sorry, it still doesn't make much sense to me I'm afraid.
>>
>> In fact, it's confused me more - since I'm using "near", does that means
>> that the "copy" (I'm using near=2) of a given trunk may lie on the same
>> disk, leading to *no redundancy*??
> Clearly I need to improve the man page... (suggestions welcome).
>
> How do you read it that the copies of a given chunk may lie on the same disk.
> I read:
>
> When 'near' replicas are chosen, the multiple copies of a given chunk
> are laid out consecutively across the stripes of the array, so the two
> copies of a datablock will likely be at the same offset on two adjacent
> devices.
>
> "laid out consecutively across the stripes of the array" might be a bit
> obscure.. A stripe is one chunk on each device, so when chunks a laid out
> consecutively across a stripe, they would be one chunk per device.
>
> Then "likely be at the same offset on two adjacent devices" should make this
> clearer. It is only "likely" because if you have an odd number of devices,
> then the 2 copies of one chunk could be
> a/ at offset X on the last device
> b/ at offset X+chunk on the first device
>
> but in general, they are on "adjacent devices"
>
> So in answer to your original question, sda5 and sdb5 will have the same
> data, and sdc5 and sdd5 will also have the same data.
>
> NeilBrown
>
Thanks for your help, Neil :)
So, just to confirm 2 drives could fail in my array, as long as the two
drives weren't sda5 and sdb5, or sdc5 and sdd5. Is that correct?
Thanks
^ permalink raw reply
* Mail etiquette
From: Phillip Susi @ 2011-06-21 14:46 UTC (permalink / raw)
To: Dragon; +Cc: linux-raid
In-Reply-To: <20110618203954.129920@gmx.net>
You keep creating new threads with no subject when you reply. This is
rude and annoying. When replying to a message you should be using your
mail client's reply function, rather than start a new message and paste
in your quotations. This should preserve the subject line and add the
proper In-Reply-To: header so that the message is properly sorted into
the existing thread. If you have been using your mail client's reply
function instead of composing a new message, then your mail client is
broken so please use another one.
On 6/18/2011 4:39 PM, Dragon wrote:
> Monitor your background reshape with "cat /proc/mdstat".
>
> When the reshape is complete, the extra disk will be marked "spare".
>
> Then you can use "mdadm --remove".
> -->after a view days the reshape was done and i take the disk out of the raid -> many thx for that
>
>> at this point i think i take the disk out of the raid, because i need the space of
> the disk.
>
> Understood, but you are living on the edge. You have no backup, and only one drive
> of redundancy. If one of your drives does fail, the odds of losing the whole array
> while replacing it is significant. Your Samsung drives claim a non-recoverable read
> error rate of 1 per 1x10^15 bits. Your eleven data disks contain 1.32x10^14 bits,
> all of which must be read during rebuild. That means a _13%_ chance of total
> failure while replacing a failed drive.
>
> I hope your 16T of data is not terribly important to you, or is otherwise replaceable.
> --> nice calculation, where do you have the data from?
> --> most of it is important, i will look for a better solution
>
>> I need another advise of you. While the computer is actualy build with 13 disk and
> i will become more data in the next month and the limit of power supply
> connecotors is reached i am looking forward to another solution. one possibility
> is to build up a better computer with more sata and sas connectors and add further
> raid-controller-cards. an other idea is to build a kind of cluster or dfs with two
> and later 3,4... computer. i read something about gluster.org. do you have a tip
> for me or experience in this?
>
> Unfortunately, no. Although I skirt the edges in my engineering work, I'm primarily
> an end-user. Both personal and work projects have relatively modest needs. From
> the engineering side, I do recommend you spend extra on power supplies& UPS.
>
> Phil
> --> and than, ext4 max size is actually 16TB, what should i do?
> --> for an end-user you have many knowledge about swraid ;)
> sunny
^ permalink raw reply
* Re: Nested RAID and booting
From: Phillip Susi @ 2011-06-21 14:28 UTC (permalink / raw)
To: lrhorer; +Cc: linux-raid
In-Reply-To: <D1.7A.00666.3AE0FED4@cdptpa-omtalb.mail.rr.com>
These days most ( all? ) distributions use udev for plug and play. When
the physical disks are detected, udev notices ( with blkid ) that they
are raid members, and runs mdadm --incremental on them. Once they are
all detected, the array goes active, and udev runs blkid on the array,
notices that is a component, and runs mdadm --incremental on that.
On 6/8/2011 1:54 AM, Leslie Rhorer wrote:
>
> For financial reasons, I have had to temporarily create two members
> of a RAID6 array by first creating a pair of RAID0 arrays from four member
> disks. The RAID6 array is currently re-shaping, and so far all seems well.
> I do have a concern about what will happen when the system reboots, however.
> In order to properly assemble the RAID6 array, the two RAID0 arrays will
> first need to be assembled and running, correct? How do I guarantee the two
> RAID0 arrays will be up before mdadm attempts to assemble the RAID6 array?
> Will simply putting them in the mdadm.conf file prior to the RAID6 array do
> the trick?
^ permalink raw reply
* reaid problem at reboot
From: william L'Heureux @ 2011-06-21 13:14 UTC (permalink / raw)
To: linux-raid
Hi,
before we start, please note that im not a pro at mdadm or lvm, and dont now the full terminology neither the full how it works.
1 week ago, 1 of my raid6 went wrong. it didnt have any superblock anymore. I know all the drives that belongs to that raid but
i
dont know the right order of the drives. I tried a python script with
assemble and permutation all combination possible. it then checks
the
header and do a e2fsck -n to check errors. Everytime i run the script i
get several and different results on each run. Some say that
the
order of the drives doesnt matter, i agree but withotuh superblock its
another story. I got another raid6 which is fine and on top of those
2
raid6, there is a lvm. if you have any question or output you want to
see, please tell me and i will provide further informations as soon as i
can
if you dont understand me, i apologize, im trying to be better at english everyday.
Thanks
William
sudo cat /dev/.mdadm/map
md0 1.2 85c93553:f5707fc9:b777b1e6:a0427190 /dev/md0
md1 1.2 32d61f75:647daf4b:c1ee26ec:bc926504 /dev/md1
cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid6 sdd1[5] sda1[4] sdi1[3] sdh1[2] sdj1[1] sdc1[0]
7809854976 blocks super 1.2 level 6, 128k chunk, algorithm 2 [6/6] [UUUUUU]
md1 : active raid6 sdk1[0] sdg1[7] sde1[6] sdf1[5] sdm1[8] sdb1[1]
7809855488 blocks super 1.2 level 6, 128k chunk, algorithm 2 [6/6] [UUUUUU]
bitmap: 0/15 pages [0KB], 65536KB chunk
mount -r /mnt/data0
mount: wrong fs type, bad option, bad superblock on /dev/mapper/vgRAID60-data0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
cat /etc/mdadm/mdadm.conf
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#
# by default, scan all partitions (/proc/partitions) for MD superblocks.
# alternatively, specify devices to scan, using wildcards if desired.
DEVICE partitions
# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes
# automatically tag new arrays as belonging to the local system
HOMEHOST <system>
# instruct the monitoring daemon where to send mail alerts
MAILADDR jeromepoulin@gmail.com
# definitions of existing MD arrays
#ARRAY /dev/md/0 metadata=1.2 UUID=d2349636:b4a0cb67:2af3246a:c7d72c9c name=BILLSSHACK:0
ARRAY /dev/md1 UUID=b52df561:301f043c:b5a7b1ab:9d934878
spares=1
#ARRAY /dev/md/3 metadata=1.2 UUID=751fd632:4baf7d64:ec26eec1:046592bc name=billsshack:3
#ARRAY /dev/md/2 metadata=1.2 UUID=cf2450e4:bc7a9cea:cb5ccda9:6f3ec87c name=billsshack:2
# This file was auto-generated on Wed, 15 Jun 2011 08:57:49 -0400
# by mkconf $Id$
--
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
^ permalink raw reply
* Re: Bug or not? Same array reports different/transformed UUID depending on check-method used.
From: jeffs_linux @ 2011-06-21 12:50 UTC (permalink / raw)
To: Luca Berra, linux-raid
In-Reply-To: <20110621054258.GA22391@maude.comedia.it>
On Tue, 21 Jun 2011 07:42 +0200, "Luca Berra" <bluca@comedia.it> wrote:
> The map_file, on the contrary, is always read and written as 4 32bit
> values in host endian order, so on x86 machines you will find it
> swapped.
>
> Summary: the mapfile is for mdadm internal use only, use mdadm commands
> (--detail, --examine) to obtain data.
>
> (*) http://en.wikipedia.org/wiki/Endianness
Ok.
How might that explain that one array IS 'swapped', and the other is
not? They're both on the same machine?
jeff
^ permalink raw reply
* Re: Which Disks can fail?
From: Jonathan Tripathy @ 2011-06-21 11:57 UTC (permalink / raw)
To: NeilBrown, linux-raid
In-Reply-To: <20110621214225.5f65ece0@notabene.brown>
On 21/06/2011 12:42, NeilBrown wrote:
> On Tue, 21 Jun 2011 11:56:41 +0100 Jonathan Tripathy<jonnyt@abpni.co.uk>
> wrote:
>
>> On 21/06/2011 11:45, NeilBrown wrote:
>>> On Tue, 21 Jun 2011 11:24:20 +0100 Jonathan Tripathy<jonnyt@abpni.co.uk>
>>> wrote:
>>>
>>>> Hi Everyone,
>>>>
>>>> Use md's "single process" RAID10 with the standard near layout (which is
>>>> apperently the same as RAID1+0 in industry), which 2 drives could fail
>>>> without loosing the array?
>>>>
>>>> This is what I have:
>>>>
>>>> Number Major Minor RaidDevice State
>>>> 0 8 5 0 active sync /dev/sda5
>>>> 1 8 21 1 active sync /dev/sdb5
>>>> 2 8 37 2 active sync /dev/sdc5
>>>> 3 8 53 3 active sync /dev/sdd5
>>>>
>>>> Thanks
>>>> --
>>>> 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
>>> Run
>>>
>>> man 4 md
>>>
>>> search for "RAID10"
>>>
>>> read what you find, and if it doesn't make sense, ask again.
>>> If it does make sense, post your answer and feel free to ask for
>>> confirmation.
>>>
>>>
>>> NeilBrown
>> Sorry, it still doesn't make much sense to me I'm afraid.
>>
>> In fact, it's confused me more - since I'm using "near", does that means
>> that the "copy" (I'm using near=2) of a given trunk may lie on the same
>> disk, leading to *no redundancy*??
> Clearly I need to improve the man page... (suggestions welcome).
>
> How do you read it that the copies of a given chunk may lie on the same disk.
> I read:
>
> When 'near' replicas are chosen, the multiple copies of a given chunk
> are laid out consecutively across the stripes of the array, so the two
> copies of a datablock will likely be at the same offset on two adjacent
> devices.
>
> "laid out consecutively across the stripes of the array" might be a bit
> obscure.. A stripe is one chunk on each device, so when chunks a laid out
> consecutively across a stripe, they would be one chunk per device.
>
> Then "likely be at the same offset on two adjacent devices" should make this
> clearer. It is only "likely" because if you have an odd number of devices,
> then the 2 copies of one chunk could be
> a/ at offset X on the last device
> b/ at offset X+chunk on the first device
>
> but in general, they are on "adjacent devices"
>
> So in answer to your original question, sda5 and sdb5 will have the same
> data, and sdc5 and sdd5 will also have the same data.
>
> NeilBrown
>
Hi Neil,
It was the lines in the "far" sections that made me have my doubts:
"When âfarâ replicas are chosen, the multiple copies of a
given chunk are laid out quite distant from each other. The
first copy of all data blocks will be striped across the early
part of all drives in RAID0 fashion, and then the next copy
of all blocks will be striped across a later section of all
drives, *always ensuring that all copies of any given block are
on different drives.*"
The highlighted part made me think that there would be a chance that
chunks would be on the same drive in near
Thanks
--
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
^ permalink raw reply
* Re: Which Disks can fail?
From: NeilBrown @ 2011-06-21 11:42 UTC (permalink / raw)
To: Jonathan Tripathy; +Cc: linux-raid
In-Reply-To: <4E0078E9.7070208@abpni.co.uk>
On Tue, 21 Jun 2011 11:56:41 +0100 Jonathan Tripathy <jonnyt@abpni.co.uk>
wrote:
>
> On 21/06/2011 11:45, NeilBrown wrote:
> > On Tue, 21 Jun 2011 11:24:20 +0100 Jonathan Tripathy<jonnyt@abpni.co.uk>
> > wrote:
> >
> >> Hi Everyone,
> >>
> >> Use md's "single process" RAID10 with the standard near layout (which is
> >> apperently the same as RAID1+0 in industry), which 2 drives could fail
> >> without loosing the array?
> >>
> >> This is what I have:
> >>
> >> Number Major Minor RaidDevice State
> >> 0 8 5 0 active sync /dev/sda5
> >> 1 8 21 1 active sync /dev/sdb5
> >> 2 8 37 2 active sync /dev/sdc5
> >> 3 8 53 3 active sync /dev/sdd5
> >>
> >> Thanks
> >> --
> >> 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
> > Run
> >
> > man 4 md
> >
> > search for "RAID10"
> >
> > read what you find, and if it doesn't make sense, ask again.
> > If it does make sense, post your answer and feel free to ask for
> > confirmation.
> >
> >
> > NeilBrown
> Sorry, it still doesn't make much sense to me I'm afraid.
>
> In fact, it's confused me more - since I'm using "near", does that means
> that the "copy" (I'm using near=2) of a given trunk may lie on the same
> disk, leading to *no redundancy*??
Clearly I need to improve the man page... (suggestions welcome).
How do you read it that the copies of a given chunk may lie on the same disk.
I read:
When 'near' replicas are chosen, the multiple copies of a given chunk
are laid out consecutively across the stripes of the array, so the two
copies of a datablock will likely be at the same offset on two adjacent
devices.
"laid out consecutively across the stripes of the array" might be a bit
obscure.. A stripe is one chunk on each device, so when chunks a laid out
consecutively across a stripe, they would be one chunk per device.
Then "likely be at the same offset on two adjacent devices" should make this
clearer. It is only "likely" because if you have an odd number of devices,
then the 2 copies of one chunk could be
a/ at offset X on the last device
b/ at offset X+chunk on the first device
but in general, they are on "adjacent devices"
So in answer to your original question, sda5 and sdb5 will have the same
data, and sdc5 and sdd5 will also have the same data.
NeilBrown
^ permalink raw reply
* Re: Which Disks can fail?
From: Jonathan Tripathy @ 2011-06-21 10:56 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <20110621204509.6309c38f@notabene.brown>
On 21/06/2011 11:45, NeilBrown wrote:
> On Tue, 21 Jun 2011 11:24:20 +0100 Jonathan Tripathy<jonnyt@abpni.co.uk>
> wrote:
>
>> Hi Everyone,
>>
>> Use md's "single process" RAID10 with the standard near layout (which is
>> apperently the same as RAID1+0 in industry), which 2 drives could fail
>> without loosing the array?
>>
>> This is what I have:
>>
>> Number Major Minor RaidDevice State
>> 0 8 5 0 active sync /dev/sda5
>> 1 8 21 1 active sync /dev/sdb5
>> 2 8 37 2 active sync /dev/sdc5
>> 3 8 53 3 active sync /dev/sdd5
>>
>> Thanks
>> --
>> 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
> Run
>
> man 4 md
>
> search for "RAID10"
>
> read what you find, and if it doesn't make sense, ask again.
> If it does make sense, post your answer and feel free to ask for
> confirmation.
>
>
> NeilBrown
Sorry, it still doesn't make much sense to me I'm afraid.
In fact, it's confused me more - since I'm using "near", does that means
that the "copy" (I'm using near=2) of a given trunk may lie on the same
disk, leading to *no redundancy*??
Thanks
^ permalink raw reply
* Re: Which Disks can fail?
From: NeilBrown @ 2011-06-21 10:45 UTC (permalink / raw)
To: Jonathan Tripathy; +Cc: linux-raid
In-Reply-To: <4E007154.9030107@abpni.co.uk>
On Tue, 21 Jun 2011 11:24:20 +0100 Jonathan Tripathy <jonnyt@abpni.co.uk>
wrote:
> Hi Everyone,
>
> Use md's "single process" RAID10 with the standard near layout (which is
> apperently the same as RAID1+0 in industry), which 2 drives could fail
> without loosing the array?
>
> This is what I have:
>
> Number Major Minor RaidDevice State
> 0 8 5 0 active sync /dev/sda5
> 1 8 21 1 active sync /dev/sdb5
> 2 8 37 2 active sync /dev/sdc5
> 3 8 53 3 active sync /dev/sdd5
>
> Thanks
> --
> 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
Run
man 4 md
search for "RAID10"
read what you find, and if it doesn't make sense, ask again.
If it does make sense, post your answer and feel free to ask for
confirmation.
NeilBrown
^ permalink raw reply
* Which Disks can fail?
From: Jonathan Tripathy @ 2011-06-21 10:24 UTC (permalink / raw)
To: linux-raid
Hi Everyone,
Use md's "single process" RAID10 with the standard near layout (which is
apperently the same as RAID1+0 in industry), which 2 drives could fail
without loosing the array?
This is what I have:
Number Major Minor RaidDevice State
0 8 5 0 active sync /dev/sda5
1 8 21 1 active sync /dev/sdb5
2 8 37 2 active sync /dev/sdc5
3 8 53 3 active sync /dev/sdd5
Thanks
^ permalink raw reply
* Re: RAID5: failing an active component during spare rebuild - arrays hangs
From: Alexander Lyakas @ 2011-06-21 8:05 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <BANLkTinr_1GcbypCpxFKPXoid4DxTKvCag@mail.gmail.com>
Anyone???...
On Mon, Jun 6, 2011 at 9:19 PM, Alexander Lyakas <alex.bolshoy@gmail.com> wrote:
>
> Hello,
>
> the kernel version is:
>
> root@ubuntu:~# uname -a
> Linux ubuntu 2.6.38-8-server #42-Ubuntu SMP Mon Apr 11 03:49:04 UTC
> 2011 x86_64 x86_64 x86_64 GNU/Linux
>
> mdadm version is:
> root@ubuntu:~# mdadm -V
> mdadm - v3.1.4 - 31st August 2010
>
> Examining the three array components:
>
> root@ubuntu:~# mdadm -E /dev/sd{a,b,c}
> /dev/sda:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x1
> Array UUID : b5802763:fd4790dd:ee8bdeb2:2418097f
> Name : vc:zvp_1123
> Creation Time : Mon Jun 6 21:10:38 2011
> Raid Level : raid5
> Raid Devices : 3
>
> Avail Dev Size : 41940992 (20.00 GiB 21.47 GB)
> Array Size : 83879936 (40.00 GiB 42.95 GB)
> Used Dev Size : 41939968 (20.00 GiB 21.47 GB)
> Data Offset : 2048 sectors
> Super Offset : 8 sectors
> State : active
> Device UUID : 8db90071:be80216e:09468262:1f5046b1
>
> Internal Bitmap : 8 sectors from superblock
> Update Time : Mon Jun 6 21:10:46 2011
> Checksum : 2e424556 - correct
> Events : 10
>
> Layout : left-symmetric
> Chunk Size : 512K
>
> Device Role : Active device 0
> Array State : A.A ('A' == active, '.' == missing)
> /dev/sdb:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x1
> Array UUID : b5802763:fd4790dd:ee8bdeb2:2418097f
> Name : vc:zvp_1123
> Creation Time : Mon Jun 6 21:10:38 2011
> Raid Level : raid5
> Raid Devices : 3
>
> Avail Dev Size : 41940992 (20.00 GiB 21.47 GB)
> Array Size : 83879936 (40.00 GiB 42.95 GB)
> Used Dev Size : 41939968 (20.00 GiB 21.47 GB)
> Data Offset : 2048 sectors
> Super Offset : 8 sectors
> State : clean
> Device UUID : 9f41313b:b1aa70f8:6cf0ca2f:c6ea0a64
>
> Internal Bitmap : 8 sectors from superblock
> Update Time : Mon Jun 6 21:10:44 2011
> Checksum : 2d23c61 - correct
> Events : 8
>
> Layout : left-symmetric
> Chunk Size : 512K
>
> Device Role : Active device 1
> Array State : AAA ('A' == active, '.' == missing)
> /dev/sdc:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x3
> Array UUID : b5802763:fd4790dd:ee8bdeb2:2418097f
> Name : vc:zvp_1123
> Creation Time : Mon Jun 6 21:10:38 2011
> Raid Level : raid5
> Raid Devices : 3
>
> Avail Dev Size : 41940992 (20.00 GiB 21.47 GB)
> Array Size : 83879936 (40.00 GiB 42.95 GB)
> Used Dev Size : 41939968 (20.00 GiB 21.47 GB)
> Data Offset : 2048 sectors
> Super Offset : 8 sectors
> Recovery Offset : 999424 sectors
> State : active
> Device UUID : 61189a9d:ec082cea:a3ba32fb:800fe84b
>
> Internal Bitmap : 8 sectors from superblock
> Update Time : Mon Jun 6 21:10:46 2011
> Checksum : a47a059 - correct
> Events : 10
>
> Layout : left-symmetric
> Chunk Size : 512K
>
> Device Role : Active device 2
> Array State : A.A ('A' == active, '.' == missing)
>
> Details about the array:
>
> root@ubuntu:~# mdadm -Q --detail /dev/md1123
> /dev/md1123:
> Version : 1.2
> Creation Time : Mon Jun 6 21:10:38 2011
> Raid Level : raid5
> Array Size : 41939968 (40.00 GiB 42.95 GB)
> Used Dev Size : 20969984 (20.00 GiB 21.47 GB)
> Raid Devices : 3
> Total Devices : 3
> Persistence : Superblock is persistent
>
> Intent Bitmap : Internal
>
> Update Time : Mon Jun 6 21:10:46 2011
> State : active, FAILED
> Active Devices : 1
> Working Devices : 2
> Failed Devices : 1
> Spare Devices : 1
>
> Layout : left-symmetric
> Chunk Size : 512K
>
> Name : vc:zvp_1123
> UUID : b5802763:fd4790dd:ee8bdeb2:2418097f
> Events : 10
>
> Number Major Minor RaidDevice State
> 0 8 0 0 active sync /dev/sda
> 1 8 16 1 faulty spare rebuilding /dev/sdb
> 3 8 32 2 spare rebuilding /dev/sdc
>
>
> Basically, the thing is that the faulty (and the rebuilding spare)
> component are not kicked out of the array, and the array is stuck in
> this state.
>
> Thanks,
> Alex.
>
>
> 2011/6/6 Nagilum <nagilum@nagilum.org>:
> > Make sure you provide all relevant details such as kernel version, mdadm
> > version and maybe also mdadm -E /dev/sd{a,b,c}, mdadm -Q --detail /dev/md0,
> > ..
> >
> > ----- Message from alex.bolshoy@gmail.com ---------
> > Date: Sun, 5 Jun 2011 22:41:55 +0300
> > From: Alexander Lyakas <alex.bolshoy@gmail.com>
> > Subject: RAID5: failing an active component during spare rebuild - arrays
> > hangs
> > To: linux-raid@vger.kernel.org
> >
> >
> >> Hello everybody,
> >> I am testing a scenario, in which I create a RAID5 with three devices:
> >> /dev/sd{a,b,c}. Since I don't supply --force to mdadm during creation,
> >> it treats the array as degraded and starts rebuilding the sdc as a
> >> spare. This is as documented.
> >>
> >> Then I do --fail on /dev/sda. I understand that at this point my data
> >> is gone, but I think should still be able to tear down the array.
> >>
> >> Sometimes I see that /dev/sda is kicked from the array as faulty, and
> >> /dev/sdc is also removed and marked as a spare. Then I am able to tear
> >> down the array.
> >>
> >> But sometimes, it looks like the system hits some kind of a deadlock.
> >> mdadm --detail produces:
> >>
> >> Update Time : Sun Jun 5 21:54:34 2011
> >> State : active, FAILED
> >> Active Devices : 1
> >> Working Devices : 2
> >> Failed Devices : 1
> >> Spare Devices : 1
> >>
> >> Layout : left-symmetric
> >> Chunk Size : 512K
> >>
> >> Name : ubuntu:zvp_1123
> >> UUID : 48a15fb6:b6410bb9:a2ca173e:0092032c
> >> Events : 67
> >>
> >> Number Major Minor RaidDevice State
> >> 0 8 0 0 faulty spare rebuilding /dev/sda
> >> 1 8 16 1 active sync /dev/sdb
> >> 3 8 32 2 spare rebuilding /dev/sdc
> >>
> >> So the faulty device and the spare are not kicked out of the array. At
> >> this point I am unable to do anything with the array:
> >>
> >> root@ubuntu:~# sudo mdadm --stop /dev/md1123
> >> mdadm: failed to stop array /dev/md1123: Device or resource busy
> >> Perhaps a running process, mounted filesystem or active volume group?
> >> root@ubuntu:~# sudo mdadm /dev/md1123 --remove /dev/sda
> >> mdadm: hot remove failed for /dev/sda: Device or resource busy
> >> root@ubuntu:~# sudo mdadm /dev/md1123 --remove /dev/sdb
> >> mdadm: hot remove failed for /dev/sdb: Device or resource busy
> >> root@ubuntu:~# sudo mdadm /dev/md1123 --remove /dev/sdc
> >> mdadm: hot remove failed for /dev/sdc: Device or resource busy
> >>
> >> This is happening on ubuntu-natty, with mdadm - v3.1.4 - 31st August 2010.
> >> Looking at some code in mdadm/Detail.c, it looks like /dev/sda has
> >> been marked only as MD_DISK_FAULTY, but has not yet been kicked out of
> >> the array. The "spare" and "rebuilding" prints also result from that.
> >>
> >> Same thing also happens (sometimes) when I manually initiate resync
> >> (by writing 'repair' to 'sync_action'), and later manually failing one
> >> of the devices. Then I also saw messages like this in the syslog:
> >> Jun 5 21:42:00 ubuntu kernel: [ 2280.350454] INFO: task
> >> md1123_resync:7993 blocked for more than 120 seconds.
> >> Jun 5 21:42:00 ubuntu kernel: [ 2280.350552] "echo 0 >
> >> /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> >> Jun 5 21:42:00 ubuntu kernel: [ 2280.350644] md1123_resync D
> >> 0000000000000000 0 7993 2 0x00000004
> >> Jun 5 21:42:00 ubuntu kernel: [ 2280.350647] ffff8800b56b1cd0
> >> 0000000000000046 ffff8800b56b1fd8 ffff8800b56b0000
> >> Jun 5 21:42:00 ubuntu kernel: [ 2280.350649] 0000000000013d00
> >> ffff880036c09a98 ffff8800b56b1fd8 0000000000013d00
> >> Jun 5 21:42:00 ubuntu kernel: [ 2280.350652] ffff8800b7f1adc0
> >> ffff880036c096e0 ffff8800b56b1cb0 ffff880036c56610
> >> Jun 5 21:42:00 ubuntu kernel: [ 2280.350654] Call Trace:
> >> Jun 5 21:42:00 ubuntu kernel: [ 2280.350657] [<ffffffff81492885>]
> >> md_do_sync+0xb45/0xc90
> >> Jun 5 21:42:00 ubuntu kernel: [ 2280.350660] [<ffffffff81087940>] ?
> >> autoremove_wake_function+0x0/0x40
> >> Jun 5 21:42:00 ubuntu kernel: [ 2280.350663] [<ffffffff8107861b>] ?
> >> recalc_sigpending+0x1b/0x50
> >> Jun 5 21:42:00 ubuntu kernel: [ 2280.350665] [<ffffffff8148c516>]
> >> md_thread+0x116/0x150
> >> Jun 5 21:42:00 ubuntu kernel: [ 2280.350667] [<ffffffff8148c400>] ?
> >> md_thread+0x0/0x150
> >> Jun 5 21:42:00 ubuntu kernel: [ 2280.350669] [<ffffffff810871f6>]
> >> kthread+0x96/0xa0
> >> Jun 5 21:42:00 ubuntu kernel: [ 2280.350672] [<ffffffff8100cde4>]
> >> kernel_thread_helper+0x4/0x10
> >> Jun 5 21:42:00 ubuntu kernel: [ 2280.350674] [<ffffffff81087160>] ?
> >> kthread+0x0/0xa0
> >> Jun 5 21:42:00 ubuntu kernel: [ 2280.350676] [<ffffffff8100cde0>] ?
> >> kernel_thread_helper+0x0/0x10
> >>
> >> This is pretty easy for me to reproduce.
> >>
> >> Basically, I would like to know what the user is expected to do when
> >> more than one RAID5 array component fails during rebuild/resync.
> >>
> >> Thanks,
> >> Alex.
> >> --
> >> 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
> >>
> >
> >
> > ----- End message from alex.bolshoy@gmail.com -----
> >
> >
> >
> > ========================================================================
> > # _ __ _ __ http://www.nagilum.org/ \n icq://69646724 #
> > # / |/ /__ ____ _(_) /_ ____ _ nagilum@nagilum.org \n +491776461165 #
> > # / / _ `/ _ `/ / / // / ' \ Amiga (68k/PPC): AOS/NetBSD/Linux #
> > # /_/|_/\_,_/\_, /_/_/\_,_/_/_/_/ Mac (PPC): MacOS-X / NetBSD /Linux #
> > # /___/ x86: FreeBSD/Linux/Solaris/Win2k ARM9: EPOC EV6 #
> > ========================================================================
> >
> >
> > ----------------------------------------------------------------
> > cakebox.homeunix.net - all the machine one needs..
> >
--
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
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox