* Re: [RFC] super1: error handling for super-block loading
From: Jes Sorensen @ 2016-05-12 18:16 UTC (permalink / raw)
To: Gioh Kim; +Cc: linux-raid, Elmar Gerdes, Jinpu Wang
In-Reply-To: <5734BFA3.1070405@profitbricks.com>
Gioh Kim <gi-oh.kim@profitbricks.com> writes:
> I'm not sure yet why mdadm failed to load super-block of disks.
> I checked the kernel log and found I/O error from disks.
> Anyway mdadm needs to handle that error case.
>
> Please review following patch.
>
> ------------------------------------------- 8<
> -------------------------------------------------------------
> From 8cacf56b2d630c7e74bad942779ff7ed5f516d26 Mon Sep 17 00:00:00 2001
> From: Gioh Kim <gi-oh.kim@profitbricks.com>
> Date: Thu, 12 May 2016 19:09:45 +0200
> Subject: [PATCH] super1: error handling for super-block loading
>
> Loading super-block can fail if all sub-devices are faulty
> or have I/O errors.
>
> Signed-off-by: Gioh Kim <gi-oh.kim@profitbricks.com>
> ---
> Grow.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/Grow.c b/Grow.c
> index f58c753..fa08522 100755
> --- a/Grow.c
> +++ b/Grow.c
> @@ -389,7 +389,7 @@ int Grow_addbitmap(char *devname, int fd, struct
> context *c, struct shape *s)
> }
> if (strcmp(s->bitmap_file, "internal") == 0 ||
> strcmp(s->bitmap_file, "clustered") == 0) {
> - int rv;
> + int rv = 0;
> int d;
> int offset_setable = 0;
> struct mdinfo *mdi;
> @@ -419,6 +419,7 @@ int Grow_addbitmap(char *devname, int fd, struct
> context *c, struct shape *s)
> if (fd2 < 0)
> continue;
> if (st->ss->load_super(st, fd2, NULL)==0) {
> + rv++;
> if (st->ss->add_internal_bitmap(
> st,
> &s->bitmap_chunk, c->delay, s->write_behind,
> @@ -435,6 +436,10 @@ int Grow_addbitmap(char *devname, int fd, struct
> context *c, struct shape *s)
> close(fd2);
> }
> }
> + if (rv == 0) {
> + pr_err("failed to load super-block.\n");
> + return 1;
> + }
> if (offset_setable) {
> st->ss->getinfo_super(st, mdi, NULL);
> sysfs_init(mdi, fd, NULL);
This is definitly not the right way to solve this problem. Error codes
are negative, and zero should _always_ mean success. Here you suddenly
introduced a new meaning to positive values of rv.
I agree handling the error case needs to be fixed, so a better way to
solve this would be to bail out when the load_super() call fails and
stop there, the same way it does if add_internal_bitmap() fails.
Ie. make it do something like this:
rv = st->ss->load_super(st, fd2, NULL)==0) {
if (!rv) {
if (st->ss->add_internal_bitmap(
....
} else {
pr_err("failed to load super-block.\n");
close(fd2);
return 1;
}
Actually looking at that code, there's a couple of things to do to clean
it up and make it more readable.
Cheers,
Jes
^ permalink raw reply
* [RFC] super1: error handling for super-block loading
From: Gioh Kim @ 2016-05-12 17:38 UTC (permalink / raw)
To: Jes Sorensen, linux-raid; +Cc: Elmar Gerdes, Jinpu Wang
Hi,
I found a segfault of mdadm.
mdadm[59966]: segfault at 5c ip 000000000042c1e1 sp 00007ffe52745390
error 4 in mdadm[400000+65000]
I disassembled mdadm.
42c170: 41 55 push %r13
42c172: 49 89 f8 mov %rdi,%r8
42c175: 41 54 push %r12
42c177: 49 89 d4 mov %rdx,%r12
42c17a: 55 push %rbp
42c17b: 53 push %rbx
42c17c: 48 89 f3 mov %rsi,%rbx
42c17f: 48 83 ec 08 sub $0x8,%rsp
42c183: f6 c3 01 test $0x1,%bl
42c186: 48 8b 6f 18 mov 0x18(%rdi),%rbp
42c18a: 44 8b 6e 1c mov 0x1c(%rsi),%r13d
42c18e: 48 89 f7 mov %rsi,%rdi
42c191: be 88 01 00 00 mov $0x188,%esi
42c196: 0f 85 b8 02 00 00 jne 42c454 <socket@plt+0x29724>
42c19c: 40 f6 c7 02 test $0x2,%dil
42c1a0: 0f 85 c2 02 00 00 jne 42c468 <socket@plt+0x29738>
42c1a6: 40 f6 c7 04 test $0x4,%dil
42c1aa: 0f 85 ce 02 00 00 jne 42c47e <socket@plt+0x2974e>
42c1b0: 89 f1 mov %esi,%ecx
42c1b2: 31 c0 xor %eax,%eax
42c1b4: c1 e9 03 shr $0x3,%ecx
42c1b7: 40 f6 c6 04 test $0x4,%sil
42c1bb: f3 48 ab rep stos %rax,%es:(%rdi)
42c1be: 74 0a je 42c1ca <socket@plt+0x2949a>
42c1c0: c7 07 00 00 00 00 movl $0x0,(%rdi)
42c1c6: 48 83 c7 04 add $0x4,%rdi
42c1ca: 40 f6 c6 02 test $0x2,%sil
42c1ce: 74 09 je 42c1d9 <socket@plt+0x294a9>
42c1d0: 66 c7 07 00 00 movw $0x0,(%rdi)
42c1d5: 48 83 c7 02 add $0x2,%rdi
42c1d9: 83 e6 01 and $0x1,%esi
42c1dc: 74 03 je 42c1e1 <socket@plt+0x294b1>
42c1de: c6 07 00 movb $0x0,(%rdi)
42c1e1: 8b 45 5c mov 0x5c(%rbp),%eax
I think this is getinfo_super1() because I rebuilt mdadm with debugging
symbol and found exactly the same assemble code.
A NULL pointer referencing is generated by reading st->sb->raid_disks
(%rdi=st, %rbp=sb=NULL).
I found there is no error handling if Grow_addbitmap fails to load
super-block.
I'm not sure yet why mdadm failed to load super-block of disks.
I checked the kernel log and found I/O error from disks.
Anyway mdadm needs to handle that error case.
Please review following patch.
------------------------------------------- 8<
-------------------------------------------------------------
From 8cacf56b2d630c7e74bad942779ff7ed5f516d26 Mon Sep 17 00:00:00 2001
From: Gioh Kim <gi-oh.kim@profitbricks.com>
Date: Thu, 12 May 2016 19:09:45 +0200
Subject: [PATCH] super1: error handling for super-block loading
Loading super-block can fail if all sub-devices are faulty
or have I/O errors.
Signed-off-by: Gioh Kim <gi-oh.kim@profitbricks.com>
---
Grow.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Grow.c b/Grow.c
index f58c753..fa08522 100755
--- a/Grow.c
+++ b/Grow.c
@@ -389,7 +389,7 @@ int Grow_addbitmap(char *devname, int fd, struct
context *c, struct shape *s)
}
if (strcmp(s->bitmap_file, "internal") == 0 ||
strcmp(s->bitmap_file, "clustered") == 0) {
- int rv;
+ int rv = 0;
int d;
int offset_setable = 0;
struct mdinfo *mdi;
@@ -419,6 +419,7 @@ int Grow_addbitmap(char *devname, int fd, struct
context *c, struct shape *s)
if (fd2 < 0)
continue;
if (st->ss->load_super(st, fd2, NULL)==0) {
+ rv++;
if (st->ss->add_internal_bitmap(
st,
&s->bitmap_chunk, c->delay, s->write_behind,
@@ -435,6 +436,10 @@ int Grow_addbitmap(char *devname, int fd, struct
context *c, struct shape *s)
close(fd2);
}
}
+ if (rv == 0) {
+ pr_err("failed to load super-block.\n");
+ return 1;
+ }
if (offset_setable) {
st->ss->getinfo_super(st, mdi, NULL);
sysfs_init(mdi, fd, NULL);
--
2.5.0
^ permalink raw reply related
* URGENT RESPONSE NEEDED, PLEASE REPLY....
From: Mr. Ragner Henderson @ 2016-05-12 14:10 UTC (permalink / raw)
To: Recipients
Dear Friend,
Pardon me for not having the pleasure of knowing your mindset before making you this offer and it is utterly confidential and genuine by virtue of its nature I write to solicit your assistance in a funds transfer deal involving £15.2M.This fund has been stashed out of the excess profit made last 2years by my branch office of the Co-operative Bank Plc here in United Kingdom which I am the manager.
I have already submitted an approved end-of-the-year report for the year 2015 to my head office here in Manchester UK. and they will never know of this excess.
I have since then, placed this amount on a Non-Investment Account without a beneficiary. Upon your response, I will configure your name on our database as holder of the Non-Investment Account. I will then guide you on how to apply to my head office for the Account Closure/bank-to-bank remittance of the funds to your designated bank account.
If you concur with this proposal, I intend for you to retain 30% of the funds while 70% shall be for me. Kindly forward your response to me immediately to my private mail box: (mr.ragnerhenderson@yahoo.com) thank you.
With Regards,
Mr. Ragner Henderson.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
--
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
* recovering failed and unrecognizable RAID5 during mdadm --grow without backup
From: Claudiu Rad @ 2016-05-12 6:22 UTC (permalink / raw)
To: linux-raid
hello all,
i am a desperate guy that 'successfully' made a chain of mistakes
leading to a real personal disaster. i need to try recover this as much
as i can as total data loss is really not acceptable.
the short story is that having a weak performance 4x4TB RAID5 (full
drives allocated to RAID5 besides the small RAID1 partitions for boot) +
LVM, after reading a few articles on the internet, i figured out i
should try some chunk size 'optimizations' and read that this can be
done with my version of mdadm and my kernel (machine running debian 7.9).
the mistakes:
1. no backup of 10TB of data. i am talking about a remote rented
server, and didn't had any easy way to do backups
2. i did run mdadm --grow -c 128 /dev/md2, it complained about
--backup-file. run the command again with the file placed in
/root/...txt, this being a partition inside the vg0 filling
/dev/md2, thus defeating the purpose. the chunk size was
automatically set to 512K before, i was trying to reduce it
3. the command returned almost immediately, didn't have any idea that
this would trigger a background process, although it is now obvious.
i then tried to see what it has done but after a ls, a second ls in
root partition was hanging. my web server panel (webmin) hanged in
'waiting for...'; tried connecting to a new shell, after providing
credentials, hanging, no cursor. i thought that my ever running
monitoring system and some other constant I/O processes running with
higher priority were clogging the system that now had lower
throughput due to parameter change and entire I/O was filled because
of this and maybe my experiments with the scheduler. actually nginx
webserver seemed to be working properly and this had nice -10
attached, which led me to this conclusion. another mistake
4. after a few minutes of unresponsive machine, decided to send a soft
CTRL+ALT+DELETE restart signal from datacenter control panel but it
wouldn't work apparently, thus, decided there is no way to exit this
situation unless using a hard restart (system reset), and this was
my final and big mistake not knowing that the array was reshaping.
the system won't boot and datacenter's rescue (network boot) system
can't see/assemble the /dev/md2 array
i assume i really did the best to destroy a working array (well, besides
not being satisfied with performance and apparent degradation during
time). into the rescue system, this is what i see so far:
root@rescue ~ # mdadm --detail --scan
ARRAY /dev/md/0 metadata=1.2 name=rescue:0
UUID=63b58acc:19623c52:c1134929:5d592d29
ARRAY /dev/md/1 metadata=1.2 name=rescue:1
UUID=94713b26:3eca44bc:dee330c8:23443240
root@rescue ~ # mdadm --examine --scan
ARRAY /dev/md/0 metadata=1.2 UUID=63b58acc:19623c52:c1134929:5d592d29
name=rescue:0
ARRAY /dev/md/1 metadata=1.2 UUID=94713b26:3eca44bc:dee330c8:23443240
name=rescue:1
ARRAY /dev/md/2 metadata=1.2 UUID=a935894f:be435fc0:589c1c7f:d5454b43
name=rescue:2
(so here the array appears)
root@rescue ~ # cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sda2[0] sdd2[3] sdc2[2] sdb2[1]
523968 blocks super 1.2 [4/4] [UUUU]
md0 : active raid1 sda1[0] sdd1[3] sdc1[2] sdb1[1]
16768896 blocks super 1.2 [4/4] [UUUU]
root@rescue ~ # mdadm --assemble --scan
mdadm: /dev/md/0 has been started with 4 drives.
mdadm: /dev/md/1 has been started with 4 drives.
mdadm: Failed to restore critical section for reshape, sorry.
Possibly you needed to specify the --backup-file
Segmentation fault
(this segmentation fault is weird)
root@rescue ~ # mdadm --assemble --scan --invalid-backup
mdadm: /dev/md/2: Need a backup file to complete reshape of this array.
mdadm: Please provided one with "--backup-file=..."
root@rescue ~ # mdadm -V
mdadm - v3.3.2 - 21st August 2014
now.. what can i best do to try as much as i can to recover my array?
the backup is actually trapped inside the / partition in the vg0 in the
array. after starting the --grow, i estimate it has been running for
about 10minutes when i did a force reboot. how can this be reconstructed
properly? i have broken it enough, i don't want to make any other move
without asking experts.
please, help. this is my greatest nightmare :(
--
Claudiu
^ permalink raw reply
* Re: problems with lots of arrays
From: Hannes Reinecke @ 2016-05-12 5:58 UTC (permalink / raw)
To: NeilBrown, Shaohua Li; +Cc: Jes Sorensen, Mike Lovell, linux-raid
In-Reply-To: <87eg98rqe1.fsf@notabene.neil.brown.name>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05/12/2016 03:55 AM, NeilBrown wrote:
> On Wed, May 11 2016, Shaohua Li wrote:
>
>> On Wed, May 11, 2016 at 08:39:53AM +1000, NeilBrown wrote:
>>> On Wed, May 11 2016, Jes Sorensen wrote:
>>>
>>>> Mike Lovell <mike.lovell@endurance.com> writes:
>>>>> we have a number of systems that have a large number of
>>>>> software arrays running. its in the couple hundred range.
>>>>> we have been using a custom built kernel based on 3.4 but
>>>>> are wanting to update to a mainline kernel and have been
>>>>> experimenting with 4.4. the systems are running recent
>>>>> centos 6 releases but we have been downgrading the mdadm
>>>>> version from 3.3.2 in 6.7 to a custom build 3.2.6. we
>>>>> installed the downgraded version due to a problem with
>>>>> array numbering. i emailed the list a while ago explaining
>>>>> the issue and submitting a patch to fix [1]. i never heard
>>>>> anything back and since we had a simple fix i didn't follow
>>>>> up on it.
>>>>
>>>> [snip]
>>>>
>>>>> what do you all think?
>>>>>
>>>>> thanks mike
>>>>>
>>>>> [1] http://marc.info/?l=linux-raid&m=142387809409798&w=2
>>>>
>>>> Staying consistent in using dev_t rather than casting back
>>>> and forth to int seems a reasonable fix to apply to mdadm. It
>>>> obviously won't change the issues with the newer kernels, but
>>>> I don't see any reason why we shouldn't apply that fix to
>>>> mdadm.
>>>>
>>>> Neil any thoughts on this?
>>>
>>> I agree that changing "int" to "dev_t" is a good idea.
>>>
>>> We should really fix the more general problem too.
>>>
>>> On any kernel with /sys/module/md_mod/parameters/new_array
>>> find_free_devnm avoid trying anything above 511. (1<<9)-1.
>>>
>>> If that fails to find a free number, then it should probably
>>> try a name like "md_NN" and act as though ci->name is set.
>>>
>>> Also, when a "name" given for the md array that is longer than
>>> 28 bytes we need to fall back to choose an array name ourselves
>>> even if ci->name is set. Start with md_512 and work upwards.
>>> Rather than probing we should read /sys/block looking for
>>> "md_*" and maybe choose 1 more than the largest number found.
>>
>> I'm wondering why udev open the device with major/minor without
>> checking if the device exists. A simple 'stat' check is neat.
>
> A big part of the role of udev is to create the device nodes in
> /dev.
>
Not any more.
devtmpfs will create the device nodes automagically,
no need for udev to interfere.
Cheers,
Hannes
- --
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJXNBttAAoJEGz4yi9OyKjPAHcP/R4+cgYjqcNH4acdGLIR9g4x
ASIieuAEe1E4/OkWcSM1pRkOMHy8fjlXw41EKBePZRshkDAL0avoPkwL6QuCbK6T
jktuTHogNKgplGyBn9ibwKBSeXlw3skDHpYU+BoIoNGJD0fGGUcFHgJQj48ptsny
mpuqyy/1LXFQCYI7Sv96cZg1InA60I6vKEJXUud78InE01bJZWS6eHCh4PH9yq9S
7l+yrnMbtMiz78TtYvgSF77CVIFgJkV8xtWO3AExTDHL1V5UtLXnAI+tS4xOtvsE
vA0NTOpiVplwJVaLEwlgRFaAZYs8zFpiko/TUitQmx7BgaxPVas30h7R0uoWhsQY
ejn6HVSQMvKJQWl0guD1JnU8CrPge36OdJnqDtLOY9Dqwqun97EriGWle8j8zpgo
yJG852IchaMYB/YPhZvag4+hDRVgqVZO4XWyC9j5pk/tPBMwFPMMk7gZSDjDKMHD
Rm11uu1O6itUJr/IDMX5broTAI6e+DJDOUn4imXjSUmTp+cWqq+HSuvQR1/Amg6S
QuOSTJbOeEF+bEM209IMmCQj6pG/Fhw2vODGrnptiFI+g5Rsf6v8/DbOnSxJhnVX
QolSvjMigykY/K7JqvjYBjtCMrwvrEgNHOAUTOD9F70SWatetLA2rAbrl71LHMgS
CByHeGYD9xkd/UzzLKy0
=4WAN
-----END PGP SIGNATURE-----
--
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: problems with lots of arrays
From: NeilBrown @ 2016-05-12 1:55 UTC (permalink / raw)
To: Shaohua Li; +Cc: Jes Sorensen, Mike Lovell, linux-raid
In-Reply-To: <20160511004550.GB127453@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2336 bytes --]
On Wed, May 11 2016, Shaohua Li wrote:
> On Wed, May 11, 2016 at 08:39:53AM +1000, NeilBrown wrote:
>> On Wed, May 11 2016, Jes Sorensen wrote:
>>
>> > Mike Lovell <mike.lovell@endurance.com> writes:
>> >> we have a number of systems that have a large number of software
>> >> arrays running. its in the couple hundred range. we have been using a
>> >> custom built kernel based on 3.4 but are wanting to update to a
>> >> mainline kernel and have been experimenting with 4.4. the systems are
>> >> running recent centos 6 releases but we have been downgrading the
>> >> mdadm version from 3.3.2 in 6.7 to a custom build 3.2.6. we installed
>> >> the downgraded version due to a problem with array numbering. i
>> >> emailed the list a while ago explaining the issue and submitting a
>> >> patch to fix [1]. i never heard anything back and since we had a
>> >> simple fix i didn't follow up on it.
>> >
>> > [snip]
>> >
>> >> what do you all think?
>> >>
>> >> thanks
>> >> mike
>> >>
>> >> [1] http://marc.info/?l=linux-raid&m=142387809409798&w=2
>> >
>> > Staying consistent in using dev_t rather than casting back and forth to
>> > int seems a reasonable fix to apply to mdadm. It obviously won't change
>> > the issues with the newer kernels, but I don't see any reason why we
>> > shouldn't apply that fix to mdadm.
>> >
>> > Neil any thoughts on this?
>>
>> I agree that changing "int" to "dev_t" is a good idea.
>>
>> We should really fix the more general problem too.
>>
>> On any kernel with /sys/module/md_mod/parameters/new_array
>> find_free_devnm avoid trying anything above 511. (1<<9)-1.
>>
>> If that fails to find a free number, then it should probably try a name
>> like "md_NN" and act as though ci->name is set.
>>
>> Also, when a "name" given for the md array that is longer than 28 bytes
>> we need to fall back to choose an array name ourselves even if ci->name
>> is set. Start with md_512 and work upwards.
>> Rather than probing we should read /sys/block looking for "md_*" and
>> maybe choose 1 more than the largest number found.
>
> I'm wondering why udev open the device with major/minor without checking if the
> device exists. A simple 'stat' check is neat.
A big part of the role of udev is to create the device nodes in /dev.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: raid 5 crashed
From: Robin Hill @ 2016-05-11 13:15 UTC (permalink / raw)
To: bobzer; +Cc: linux-raid
In-Reply-To: <CADzS=aoMEaFv5TPYUpYBnLhOpF+u9dtG6aa=JZ5gd=Qv1=OrMQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7875 bytes --]
On Tue May 10, 2016 at 11:28:31PM +0200, bobzer wrote:
> hi everyone,
>
> I'm in panic mode :-( because i got a raid 5 with 4 disk but 2 removed
> yesterday i got a power outage which removed one disk. the disks
> sd[bcd]1 was ok and saying that sde1 is removed but sde1 said that
> everything is fine.
> so i stop the raid, zero the superblock of sde1, start the raid and
> add sde1 to the raid. then it start to reconstruct, i think it had
> time to finish before this problem (i'm not 100% sure that it finish
> but i think so)
> the data was accessible so i went to sleep
> today i discovered the raid in this state :
>
> root@serveur:/home/math# mdadm -D /dev/md0
> /dev/md0:
> Version : 1.2
> Creation Time : Sun Mar 4 22:49:14 2012
> Raid Level : raid5
> Array Size : 5860532352 (5589.04 GiB 6001.19 GB)
> Used Dev Size : 1953510784 (1863.01 GiB 2000.40 GB)
> Raid Devices : 4
> Total Devices : 4
> Persistence : Superblock is persistent
>
> Update Time : Fri May 6 17:44:02 2016
> State : clean, FAILED
> Active Devices : 2
> Working Devices : 3
> Failed Devices : 1
> Spare Devices : 1
>
> Layout : left-symmetric
> Chunk Size : 128K
>
> Name : debian:0
> UUID : bf3c605b:9699aa55:d45119a2:7ba58d56
> Events : 892482
>
> Number Major Minor RaidDevice State
> 3 8 33 0 active sync /dev/sdc1
> 1 8 49 1 active sync /dev/sdd1
> 4 0 0 4 removed
> 6 0 0 6 removed
>
> 4 8 17 - faulty /dev/sdb1
> 5 8 65 - spare /dev/sde1
>
So this reports /dev/sdb1 faulty and /dev/sde1 spare. That would
indicate that the rebuild hadn't finished.
> root@serveur:/home/math# mdadm --examine /dev/sdb1
> /dev/sdb1:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x0
> Array UUID : bf3c605b:9699aa55:d45119a2:7ba58d56
> Name : debian:0
> Creation Time : Sun Mar 4 22:49:14 2012
> Raid Level : raid5
> Raid Devices : 4
>
> Avail Dev Size : 3907021954 (1863.01 GiB 2000.40 GB)
> Array Size : 5860532352 (5589.04 GiB 6001.19 GB)
> Used Dev Size : 3907021568 (1863.01 GiB 2000.40 GB)
> Data Offset : 2048 sectors
> Super Offset : 8 sectors
> Unused Space : before=1960 sectors, after=386 sectors
> State : clean
> Device UUID : 9bececcb:d520ca38:fd88d956:5718e361
>
> Update Time : Fri May 6 02:07:00 2016
> Bad Block Log : 512 entries available at offset 72 sectors
> Checksum : dc2a133a - correct
> Events : 892215
>
> Layout : left-symmetric
> Chunk Size : 128K
>
> Device Role : Active device 2
> Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
>
We can see /dev/sdb1 has a lower event count than the others and also
that it indicates all the drives in the array were active when it was
last running. That would strongly suggest that it was not in the array
when /dev/sde1 was added to rebuild. The update time is also nearly 16
hours earlier than that of the other drives.
> root@serveur:/home/math# mdadm --examine /dev/sdc1
> /dev/sdc1:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x0
> Array UUID : bf3c605b:9699aa55:d45119a2:7ba58d56
> Name : debian:0
> Creation Time : Sun Mar 4 22:49:14 2012
> Raid Level : raid5
> Raid Devices : 4
>
> Avail Dev Size : 3907021954 (1863.01 GiB 2000.40 GB)
> Array Size : 5860532352 (5589.04 GiB 6001.19 GB)
> Used Dev Size : 3907021568 (1863.01 GiB 2000.40 GB)
> Data Offset : 2048 sectors
> Super Offset : 8 sectors
> Unused Space : before=1960 sectors, after=386 sectors
> State : clean
> Device UUID : 1ecaf51c:3289a902:7bb71a93:237c68e8
>
> Update Time : Fri May 6 17:58:27 2016
> Bad Block Log : 512 entries available at offset 72 sectors
> Checksum : b9d6aa84 - correct
> Events : 892484
>
> Layout : left-symmetric
> Chunk Size : 128K
>
> Device Role : Active device 0
> Array State : AA.. ('A' == active, '.' == missing, 'R' == replacing)
>
> root@serveur:/home/math# mdadm --examine /dev/sdd1
> /dev/sdd1:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x0
> Array UUID : bf3c605b:9699aa55:d45119a2:7ba58d56
> Name : debian:0
> Creation Time : Sun Mar 4 22:49:14 2012
> Raid Level : raid5
> Raid Devices : 4
>
> Avail Dev Size : 3907021954 (1863.01 GiB 2000.40 GB)
> Array Size : 5860532352 (5589.04 GiB 6001.19 GB)
> Used Dev Size : 3907021568 (1863.01 GiB 2000.40 GB)
> Data Offset : 2048 sectors
> Super Offset : 8 sectors
> Unused Space : before=0 sectors, after=386 sectors
> State : clean
> Device UUID : 406c4cb5:c188e4a9:7ed8be9f:14a49b16
>
> Update Time : Fri May 6 17:58:27 2016
> Bad Block Log : 512 entries available at offset 2032 sectors
> Checksum : 343f9cd0 - correct
> Events : 892484
>
> Layout : left-symmetric
> Chunk Size : 128K
>
> Device Role : Active device 1
> Array State : AA.. ('A' == active, '.' == missing, 'R' == replacing)
>
These two drives contain the same information. They indicate that they
were the only 2 running members in the array when they were last updated.
> root@serveur:/home/math# mdadm --examine /dev/sde1
> /dev/sde1:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x8
> Array UUID : bf3c605b:9699aa55:d45119a2:7ba58d56
> Name : debian:0
> Creation Time : Sun Mar 4 22:49:14 2012
> Raid Level : raid5
> Raid Devices : 4
>
> Avail Dev Size : 3907025072 (1863.01 GiB 2000.40 GB)
> Array Size : 5860532352 (5589.04 GiB 6001.19 GB)
> Used Dev Size : 3907021568 (1863.01 GiB 2000.40 GB)
> Data Offset : 2048 sectors
> Super Offset : 8 sectors
> Unused Space : before=1960 sectors, after=3504 sectors
> State : clean
> Device UUID : f2e9c1ec:2852cf21:1a588581:b9f49a8b
>
> Update Time : Fri May 6 17:58:27 2016
> Bad Block Log : 512 entries available at offset 72 sectors - bad
> blocks present.
> Checksum : 3a65b8bc - correct
> Events : 892484
>
> Layout : left-symmetric
> Chunk Size : 128K
>
> Device Role : spare
> Array State : AA.. ('A' == active, '.' == missing, 'R' == replacing)
>
And finally /dev/sde1 shows as a spare, with the rest of the data
matching /dev/sdc1 and /dev/sde1.
> PLEASE help me :-) i don't know what to do so i did nothing to not do
> any stupid things
> 1000 thank you
>
> ps i just saw this, i hope it not mak y case worst
> root@serveur:/home/math# cat /etc/mdadm/mdadm.conf
> DEVICE /dev/sd[bcd]1
> ARRAY /dev/md0 metadata=1.2 name=debian:0
> UUID=bf3c605b:9699aa55:d45119a2:7ba58d56
>
From the data here, if looks to me as though /dev/sdb1 failed originally
(hence it thinks the array was complete). Either then /dev/sde1 also
failed, or you've proceeded to zero the superblock on the wrong drive.
You really need to look through the system logs and verify what happened
when and to what disk (if you rebooted at any point, the drive ordering
may have changed, so don't take for granted that the drive names are
consistent throughout).
Cheers,
Robin
--
___
( ' } | Robin Hill <robin@robinhill.me.uk> |
/ / ) | Little Jim says .... |
// !! | "He fallen in de water !!" |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: raid 5 crashed
From: Mikael Abrahamsson @ 2016-05-11 12:09 UTC (permalink / raw)
To: bobzer; +Cc: linux-raid
In-Reply-To: <CADzS=aoMEaFv5TPYUpYBnLhOpF+u9dtG6aa=JZ5gd=Qv1=OrMQ@mail.gmail.com>
On Tue, 10 May 2016, bobzer wrote:
> PLEASE help me :-) i don't know what to do so i did nothing to not do
> any stupid things 1000 thank you
What does dmesg say? Did you get read error on one of the remaining 3
drives? Then you need to look into the archives to use dd_rescue to get as
much data off of that drive as possible, and try again.
It would also help if you provided what kernel version and mdadm version
you're using.
Before you try again, also do this:
for x in /sys/block/sd[a-z] ; do
echo 180 > $x/device/timeout
done
This makes sure the kernel will not kick a drive that might take long to
respond due to read errors.
--
Mikael Abrahamsson email: swmike@swm.pp.se
^ permalink raw reply
* [PATCH] super1: add more checks for NodeNumUpdate option
From: Guoqing Jiang @ 2016-05-11 9:31 UTC (permalink / raw)
To: Jes.Sorensen; +Cc: linux-raid, Guoqing Jiang
There are some cases which didn't need to check the space
is enough or not for NodeNumUpdate option.
1. for array which does not have clustered bitmap.
2. "--nodes" parameter is 0 (eg, add a disk to clustered raid).
3. if "--nodes" parameter is set to a smaller num than
current bms->nodes.
Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
---
super1.c | 22 +++++++++++++++++++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/super1.c b/super1.c
index fa93367..3d25fae 100644
--- a/super1.c
+++ b/super1.c
@@ -2394,9 +2394,25 @@ static int write_bitmap1(struct supertype *st, int fd, enum bitmap_update update
return -EINVAL;
}
- if (bms->version == BITMAP_MAJOR_CLUSTERED && st->nodes <= 1) {
- pr_err("Warning: cluster-md at least needs two nodes\n");
- return -EINVAL;
+ if (bms->version == BITMAP_MAJOR_CLUSTERED) {
+ if (st->nodes == 1) {
+ /* the parameter for nodes is not valid */
+ pr_err("Warning: cluster-md at least needs two nodes\n");
+ return -EINVAL;
+ } else if (st->nodes == 0)
+ /* --nodes is not specified */
+ break;
+ else if (__cpu_to_le32(st->nodes) < bms->nodes) {
+ /* Since the nodes num is not increased, no need to check the space
+ * is enough or not, just update bms->nodes */
+ bms->nodes = __cpu_to_le32(st->nodes);
+ break;
+ }
+ } else {
+ /* no need to change bms->nodes for other bitmap types */
+ if (st->nodes)
+ pr_err("Warning: --nodes option is only suitable for clustered bitmap\n");
+ break;
}
/* Each node has an independent bitmap, it is necessary to calculate the
--
2.6.2
^ permalink raw reply related
* Re: problems with lots of arrays
From: Shaohua Li @ 2016-05-11 0:45 UTC (permalink / raw)
To: NeilBrown; +Cc: Jes Sorensen, Mike Lovell, linux-raid
In-Reply-To: <87wpn1sfk6.fsf@notabene.neil.brown.name>
On Wed, May 11, 2016 at 08:39:53AM +1000, NeilBrown wrote:
> On Wed, May 11 2016, Jes Sorensen wrote:
>
> > Mike Lovell <mike.lovell@endurance.com> writes:
> >> we have a number of systems that have a large number of software
> >> arrays running. its in the couple hundred range. we have been using a
> >> custom built kernel based on 3.4 but are wanting to update to a
> >> mainline kernel and have been experimenting with 4.4. the systems are
> >> running recent centos 6 releases but we have been downgrading the
> >> mdadm version from 3.3.2 in 6.7 to a custom build 3.2.6. we installed
> >> the downgraded version due to a problem with array numbering. i
> >> emailed the list a while ago explaining the issue and submitting a
> >> patch to fix [1]. i never heard anything back and since we had a
> >> simple fix i didn't follow up on it.
> >
> > [snip]
> >
> >> what do you all think?
> >>
> >> thanks
> >> mike
> >>
> >> [1] http://marc.info/?l=linux-raid&m=142387809409798&w=2
> >
> > Staying consistent in using dev_t rather than casting back and forth to
> > int seems a reasonable fix to apply to mdadm. It obviously won't change
> > the issues with the newer kernels, but I don't see any reason why we
> > shouldn't apply that fix to mdadm.
> >
> > Neil any thoughts on this?
>
> I agree that changing "int" to "dev_t" is a good idea.
>
> We should really fix the more general problem too.
>
> On any kernel with /sys/module/md_mod/parameters/new_array
> find_free_devnm avoid trying anything above 511. (1<<9)-1.
>
> If that fails to find a free number, then it should probably try a name
> like "md_NN" and act as though ci->name is set.
>
> Also, when a "name" given for the md array that is longer than 28 bytes
> we need to fall back to choose an array name ourselves even if ci->name
> is set. Start with md_512 and work upwards.
> Rather than probing we should read /sys/block looking for "md_*" and
> maybe choose 1 more than the largest number found.
I'm wondering why udev open the device with major/minor without checking if the
device exists. A simple 'stat' check is neat.
Thanks,
Shaohua
^ permalink raw reply
* Re: [PATCH] md: make the code more readable in the for-loop
From: Shaohua Li @ 2016-05-11 0:29 UTC (permalink / raw)
To: Jes Sorensen; +Cc: NeilBrown, Eyal Lebedinsky, linux-raid, kernelpatch
In-Reply-To: <wrfjd1ovrmdp.fsf@redhat.com>
On Mon, May 09, 2016 at 04:45:38PM -0400, Jes Sorensen wrote:
> NeilBrown <nfbrown@novell.com> writes:
> > On Mon, May 09 2016, Shaohua Li wrote:
> >
> >> On Mon, May 09, 2016 at 09:33:39AM +1000, Eyal Lebedinsky wrote:
> >>> I do not see how this change makes it clearer. The original form is
> >>> actually a very common and clear
> >>> scan an array in reverse order
> >>
> >> People always have different opinions for this stuff. When I read '--j' or
> >> 'j--', I always think extra time what the value of j is. So for me the change
> >> actually makes the code more readable :)
> >
> > If the goal is to make the code more readable, you may as well make it:
> >
> > for (j = 0; i < ->raid_disk; j++)
> >
> > That will be clearer to most people than the current code, which I don't
> > think is very much clearer than the original (maybe a little bit).
>
> I agree - I had to read the updated version multiple times to convince
> myself it was doing the same thing as the original.
ok, droped the patch. If Tiezhu Yang is willing to post a new one as neil
suggested, I'll still apply. To be honest I hate the 'j--' and check 'j' stuff.
Thanks,
Shaohua
^ permalink raw reply
* [PATCH v1] dm-crypt: replace custom implementation of hex2bin()
From: Andy Shevchenko @ 2016-05-10 23:24 UTC (permalink / raw)
To: dm-devel, Mike Snitzer, linux-raid; +Cc: Andy Shevchenko
There is no need to have a duplication of the generic library, i.e. hex2bin().
Replace the open coded variant.
Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
drivers/md/dm-crypt.c | 27 ++-------------------------
1 file changed, 2 insertions(+), 25 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 4f3cb35..eb30284 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -1407,30 +1407,6 @@ static void kcryptd_queue_crypt(struct dm_crypt_io *io)
queue_work(cc->crypt_queue, &io->work);
}
-/*
- * Decode key from its hex representation
- */
-static int crypt_decode_key(u8 *key, char *hex, unsigned int size)
-{
- char buffer[3];
- unsigned int i;
-
- buffer[2] = '\0';
-
- for (i = 0; i < size; i++) {
- buffer[0] = *hex++;
- buffer[1] = *hex++;
-
- if (kstrtou8(buffer, 16, &key[i]))
- return -EINVAL;
- }
-
- if (*hex != '\0')
- return -EINVAL;
-
- return 0;
-}
-
static void crypt_free_tfms(struct crypt_config *cc)
{
unsigned i;
@@ -1502,7 +1478,8 @@ static int crypt_set_key(struct crypt_config *cc, char *key)
if (!cc->key_size && strcmp(key, "-"))
goto out;
- if (cc->key_size && crypt_decode_key(cc->key, key, cc->key_size) < 0)
+ /* Decode key from its hex representation. */
+ if (cc->key_size && hex2bin(cc->key, key, cc->key_size) < 0)
goto out;
set_bit(DM_CRYPT_KEY_VALID, &cc->flags);
--
2.8.2
^ permalink raw reply related
* Re: problems with lots of arrays
From: NeilBrown @ 2016-05-10 22:39 UTC (permalink / raw)
To: Jes Sorensen, Mike Lovell; +Cc: linux-raid
In-Reply-To: <wrfj8tzhk5by.fsf@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1850 bytes --]
On Wed, May 11 2016, Jes Sorensen wrote:
> Mike Lovell <mike.lovell@endurance.com> writes:
>> we have a number of systems that have a large number of software
>> arrays running. its in the couple hundred range. we have been using a
>> custom built kernel based on 3.4 but are wanting to update to a
>> mainline kernel and have been experimenting with 4.4. the systems are
>> running recent centos 6 releases but we have been downgrading the
>> mdadm version from 3.3.2 in 6.7 to a custom build 3.2.6. we installed
>> the downgraded version due to a problem with array numbering. i
>> emailed the list a while ago explaining the issue and submitting a
>> patch to fix [1]. i never heard anything back and since we had a
>> simple fix i didn't follow up on it.
>
> [snip]
>
>> what do you all think?
>>
>> thanks
>> mike
>>
>> [1] http://marc.info/?l=linux-raid&m=142387809409798&w=2
>
> Staying consistent in using dev_t rather than casting back and forth to
> int seems a reasonable fix to apply to mdadm. It obviously won't change
> the issues with the newer kernels, but I don't see any reason why we
> shouldn't apply that fix to mdadm.
>
> Neil any thoughts on this?
I agree that changing "int" to "dev_t" is a good idea.
We should really fix the more general problem too.
On any kernel with /sys/module/md_mod/parameters/new_array
find_free_devnm avoid trying anything above 511. (1<<9)-1.
If that fails to find a free number, then it should probably try a name
like "md_NN" and act as though ci->name is set.
Also, when a "name" given for the md array that is longer than 28 bytes
we need to fall back to choose an array name ourselves even if ci->name
is set. Start with md_512 and work upwards.
Rather than probing we should read /sys/block looking for "md_*" and
maybe choose 1 more than the largest number found.
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* raid 5 crashed
From: bobzer @ 2016-05-10 21:28 UTC (permalink / raw)
To: linux-raid
hi everyone,
I'm in panic mode :-( because i got a raid 5 with 4 disk but 2 removed
yesterday i got a power outage which removed one disk. the disks
sd[bcd]1 was ok and saying that sde1 is removed but sde1 said that
everything is fine.
so i stop the raid, zero the superblock of sde1, start the raid and
add sde1 to the raid. then it start to reconstruct, i think it had
time to finish before this problem (i'm not 100% sure that it finish
but i think so)
the data was accessible so i went to sleep
today i discovered the raid in this state :
root@serveur:/home/math# mdadm -D /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Sun Mar 4 22:49:14 2012
Raid Level : raid5
Array Size : 5860532352 (5589.04 GiB 6001.19 GB)
Used Dev Size : 1953510784 (1863.01 GiB 2000.40 GB)
Raid Devices : 4
Total Devices : 4
Persistence : Superblock is persistent
Update Time : Fri May 6 17:44:02 2016
State : clean, FAILED
Active Devices : 2
Working Devices : 3
Failed Devices : 1
Spare Devices : 1
Layout : left-symmetric
Chunk Size : 128K
Name : debian:0
UUID : bf3c605b:9699aa55:d45119a2:7ba58d56
Events : 892482
Number Major Minor RaidDevice State
3 8 33 0 active sync /dev/sdc1
1 8 49 1 active sync /dev/sdd1
4 0 0 4 removed
6 0 0 6 removed
4 8 17 - faulty /dev/sdb1
5 8 65 - spare /dev/sde1
root@serveur:/home/math# mdadm --examine /dev/sdb1
/dev/sdb1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : bf3c605b:9699aa55:d45119a2:7ba58d56
Name : debian:0
Creation Time : Sun Mar 4 22:49:14 2012
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 3907021954 (1863.01 GiB 2000.40 GB)
Array Size : 5860532352 (5589.04 GiB 6001.19 GB)
Used Dev Size : 3907021568 (1863.01 GiB 2000.40 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
Unused Space : before=1960 sectors, after=386 sectors
State : clean
Device UUID : 9bececcb:d520ca38:fd88d956:5718e361
Update Time : Fri May 6 02:07:00 2016
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : dc2a133a - correct
Events : 892215
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 2
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
root@serveur:/home/math# mdadm --examine /dev/sdc1
/dev/sdc1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : bf3c605b:9699aa55:d45119a2:7ba58d56
Name : debian:0
Creation Time : Sun Mar 4 22:49:14 2012
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 3907021954 (1863.01 GiB 2000.40 GB)
Array Size : 5860532352 (5589.04 GiB 6001.19 GB)
Used Dev Size : 3907021568 (1863.01 GiB 2000.40 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
Unused Space : before=1960 sectors, after=386 sectors
State : clean
Device UUID : 1ecaf51c:3289a902:7bb71a93:237c68e8
Update Time : Fri May 6 17:58:27 2016
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : b9d6aa84 - correct
Events : 892484
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 0
Array State : AA.. ('A' == active, '.' == missing, 'R' == replacing)
root@serveur:/home/math# mdadm --examine /dev/sdd1
/dev/sdd1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : bf3c605b:9699aa55:d45119a2:7ba58d56
Name : debian:0
Creation Time : Sun Mar 4 22:49:14 2012
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 3907021954 (1863.01 GiB 2000.40 GB)
Array Size : 5860532352 (5589.04 GiB 6001.19 GB)
Used Dev Size : 3907021568 (1863.01 GiB 2000.40 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
Unused Space : before=0 sectors, after=386 sectors
State : clean
Device UUID : 406c4cb5:c188e4a9:7ed8be9f:14a49b16
Update Time : Fri May 6 17:58:27 2016
Bad Block Log : 512 entries available at offset 2032 sectors
Checksum : 343f9cd0 - correct
Events : 892484
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 1
Array State : AA.. ('A' == active, '.' == missing, 'R' == replacing)
root@serveur:/home/math# mdadm --examine /dev/sde1
/dev/sde1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x8
Array UUID : bf3c605b:9699aa55:d45119a2:7ba58d56
Name : debian:0
Creation Time : Sun Mar 4 22:49:14 2012
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 3907025072 (1863.01 GiB 2000.40 GB)
Array Size : 5860532352 (5589.04 GiB 6001.19 GB)
Used Dev Size : 3907021568 (1863.01 GiB 2000.40 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
Unused Space : before=1960 sectors, after=3504 sectors
State : clean
Device UUID : f2e9c1ec:2852cf21:1a588581:b9f49a8b
Update Time : Fri May 6 17:58:27 2016
Bad Block Log : 512 entries available at offset 72 sectors - bad
blocks present.
Checksum : 3a65b8bc - correct
Events : 892484
Layout : left-symmetric
Chunk Size : 128K
Device Role : spare
Array State : AA.. ('A' == active, '.' == missing, 'R' == replacing)
PLEASE help me :-) i don't know what to do so i did nothing to not do
any stupid things
1000 thank you
ps i just saw this, i hope it not mak y case worst
root@serveur:/home/math# cat /etc/mdadm/mdadm.conf
DEVICE /dev/sd[bcd]1
ARRAY /dev/md0 metadata=1.2 name=debian:0
UUID=bf3c605b:9699aa55:d45119a2:7ba58d56
^ permalink raw reply
* Re: problems with lots of arrays
From: Jes Sorensen @ 2016-05-10 20:48 UTC (permalink / raw)
To: Mike Lovell; +Cc: linux-raid, NeilBrown
In-Reply-To: <CAK9wOaB+Cic3nR5kzB3n=nVpbRtfo8+Qr9j_VNM3hh5tJRw6YA@mail.gmail.com>
Mike Lovell <mike.lovell@endurance.com> writes:
> we have a number of systems that have a large number of software
> arrays running. its in the couple hundred range. we have been using a
> custom built kernel based on 3.4 but are wanting to update to a
> mainline kernel and have been experimenting with 4.4. the systems are
> running recent centos 6 releases but we have been downgrading the
> mdadm version from 3.3.2 in 6.7 to a custom build 3.2.6. we installed
> the downgraded version due to a problem with array numbering. i
> emailed the list a while ago explaining the issue and submitting a
> patch to fix [1]. i never heard anything back and since we had a
> simple fix i didn't follow up on it.
[snip]
> what do you all think?
>
> thanks
> mike
>
> [1] http://marc.info/?l=linux-raid&m=142387809409798&w=2
Staying consistent in using dev_t rather than casting back and forth to
int seems a reasonable fix to apply to mdadm. It obviously won't change
the issues with the newer kernels, but I don't see any reason why we
shouldn't apply that fix to mdadm.
Neil any thoughts on this?
Cheers,
Jes
^ permalink raw reply
* Re: [PATCH] md: raid5: add prerequisite to run underneath dm-raid
From: Heinz Mauelshagen @ 2016-05-09 21:31 UTC (permalink / raw)
To: Jes Sorensen; +Cc: linux-raid
In-Reply-To: <wrfj8tzjrmbd.fsf@redhat.com>
On 05/09/2016 10:47 PM, Jes Sorensen wrote:
> heinzm@redhat.com writes:
>> From: Heinz Mauelshagen <heinzm@redhat.com>
>>
>> In case md runs underneath the dm-raid target, the mddev does not have
>> a request queue or gendisk, thus avoid accesses.
>>
>> This patch adds a missing conditional to the raid5 personality.
>>
>>
>> Signed-of-by: Heinz Mauelshagen <heinzm@redhat.com>
>>
>>
>> ---
>> drivers/md/raid5.c | 6 ++++--
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
>> index 8ab8b65..ce79ce6 100644
>> --- a/drivers/md/raid5.c
>> +++ b/drivers/md/raid5.c
>> @@ -7574,8 +7574,10 @@ static void raid5_finish_reshape(struct mddev *mddev)
>>
>> if (mddev->delta_disks > 0) {
>> md_set_array_sectors(mddev, raid5_size(mddev, 0, 0));
>> - set_capacity(mddev->gendisk, mddev->array_sectors);
>> - revalidate_disk(mddev->gendisk);
>> + if (mddev->queue) {
>> + set_capacity(mddev->gendisk, mddev->array_sectors);
>> + revalidate_disk(mddev->gendisk);
>> + }
> Since we're in the code taste mode, this is a reminder that kernel code
> is 80 characters per line :)
Hehe, gotta shorten > 20 lines in raid5.c alone then :-)
Heinz
>
> Jes
^ permalink raw reply
* Re: [PATCH] md: raid5: add prerequisite to run underneath dm-raid
From: Jes Sorensen @ 2016-05-09 20:47 UTC (permalink / raw)
To: heinzm; +Cc: linux-raid
In-Reply-To: <1462809009-2809-1-git-send-email-heinzm@redhat.com>
heinzm@redhat.com writes:
> From: Heinz Mauelshagen <heinzm@redhat.com>
>
> In case md runs underneath the dm-raid target, the mddev does not have
> a request queue or gendisk, thus avoid accesses.
>
> This patch adds a missing conditional to the raid5 personality.
>
>
> Signed-of-by: Heinz Mauelshagen <heinzm@redhat.com>
>
>
> ---
> drivers/md/raid5.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index 8ab8b65..ce79ce6 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -7574,8 +7574,10 @@ static void raid5_finish_reshape(struct mddev *mddev)
>
> if (mddev->delta_disks > 0) {
> md_set_array_sectors(mddev, raid5_size(mddev, 0, 0));
> - set_capacity(mddev->gendisk, mddev->array_sectors);
> - revalidate_disk(mddev->gendisk);
> + if (mddev->queue) {
> + set_capacity(mddev->gendisk, mddev->array_sectors);
> + revalidate_disk(mddev->gendisk);
> + }
Since we're in the code taste mode, this is a reminder that kernel code
is 80 characters per line :)
Jes
^ permalink raw reply
* Re: [PATCH] md: make the code more readable in the for-loop
From: Jes Sorensen @ 2016-05-09 20:45 UTC (permalink / raw)
To: NeilBrown; +Cc: Shaohua Li, Eyal Lebedinsky, linux-raid
In-Reply-To: <87inynu4he.fsf@notabene.neil.brown.name>
NeilBrown <nfbrown@novell.com> writes:
> On Mon, May 09 2016, Shaohua Li wrote:
>
>> On Mon, May 09, 2016 at 09:33:39AM +1000, Eyal Lebedinsky wrote:
>>> I do not see how this change makes it clearer. The original form is
>>> actually a very common and clear
>>> scan an array in reverse order
>>
>> People always have different opinions for this stuff. When I read '--j' or
>> 'j--', I always think extra time what the value of j is. So for me the change
>> actually makes the code more readable :)
>
> If the goal is to make the code more readable, you may as well make it:
>
> for (j = 0; i < ->raid_disk; j++)
>
> That will be clearer to most people than the current code, which I don't
> think is very much clearer than the original (maybe a little bit).
I agree - I had to read the updated version multiple times to convince
myself it was doing the same thing as the original.
Cheers,
Jes
^ permalink raw reply
* Re: [PATCH] super1: make the check for NodeNumUpdate more accurate
From: Jes Sorensen @ 2016-05-09 19:01 UTC (permalink / raw)
To: Guoqing Jiang; +Cc: linux-raid
In-Reply-To: <1462760578-1429-1-git-send-email-gqjiang@suse.com>
Guoqing Jiang <gqjiang@suse.com> writes:
> We missed to check the version is BITMAP_MAJOR_CLUSTERED
> or not, otherwise mdadm can't create array with other 1.x
> metadatas (1.0 and 1.1).
>
> Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
> ---
> super1.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied!
Also applied the two patches from last week.
Thanks,
Jes
^ permalink raw reply
* Re: RAID5 - reshape_position too early for auto-recovery - aborting
From: SharksArt @ 2016-05-09 16:43 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <CAJwyido42Gk0uoMCKCLXk0dLfJ+J91uS=4N359fG0jkwg=jAGw@mail.gmail.com>
Hi,
I searched again on this mailing list and i've just found the
--update=revert-reshape and it works well ! My RAID 5 is now up and my
volume is Ok :)
In my case : mdadm --assemble --verbose --force --update=revert-reshape
--invalid-backup --backup-file=/whatever /dev/md/3 /dev/sd[bcdefg]6
Now, i will make a full backup of my datas before growing ^_^'
Laurent
^ permalink raw reply
* Re: [PATCH] md: raid5: add prerequisite to run underneath dm-raid
From: Shaohua Li @ 2016-05-09 16:42 UTC (permalink / raw)
To: heinzm; +Cc: linux-raid
In-Reply-To: <1462809009-2809-1-git-send-email-heinzm@redhat.com>
On Mon, May 09, 2016 at 05:50:09PM +0200, heinzm@redhat.com wrote:
> From: Heinz Mauelshagen <heinzm@redhat.com>
>
> In case md runs underneath the dm-raid target, the mddev does not have
> a request queue or gendisk, thus avoid accesses.
>
> This patch adds a missing conditional to the raid5 personality.
already added the 3 patches to my tree since you last post. I probably forgot
to reply you though, sorry.
^ permalink raw reply
* Re: md: md.c: fix oops in mddev_suspend for raid0
From: Mike Snitzer @ 2016-05-09 16:08 UTC (permalink / raw)
To: heinzm; +Cc: dm-devel, shli, linux-raid
In-Reply-To: <1462809042-2974-1-git-send-email-heinzm@redhat.com>
On Mon, May 09 2016 at 11:50am -0400,
heinzm@redhat.com <heinzm@redhat.com> wrote:
> From: Heinz Mauelshagen <heinzm@redhat.com>
>
> Introduced by upstream commit 70d9798b95562abac005d4ba71d28820f9a201eb
>
> The raid0 personality does not create mddev->thread as oposed to
> other personalities leading to its unconditional access in
> mddev_suspend() causing an oops.
>
> Patch checks for mddev->thread in order to keep the
> intention of aforementioned commit.
>
> Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com>
Seems this should be marked with:
Fixes: 70d9798b9556 ("MD: warn for potential deadlock")
Cc: stable@vger.kernel.org # 4.5+
>
>
> ---
> drivers/md/md.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 194580f..d91920d 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -305,7 +305,7 @@ static blk_qc_t md_make_request(struct request_queue *q, struct bio *bio)
> */
> void mddev_suspend(struct mddev *mddev)
> {
> - WARN_ON_ONCE(current == mddev->thread->tsk);
> + WARN_ON_ONCE(mddev->thread && current == mddev->thread->tsk);
> if (mddev->suspended++)
> return;
> synchronize_rcu();
> --
> 2.5.5
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply
* [PATCH] [REGRESSION] md: md.c: fix oops in mddev_suspend for raid0
From: heinzm @ 2016-05-09 16:03 UTC (permalink / raw)
To: linux-raid; +Cc: Heinz Mauelshagen
From: Heinz Mauelshagen <heinzm@redhat.com>
Introduced by upstream commit 70d9798b95562abac005d4ba71d28820f9a201eb
The raid0 personality does not create mddev->thread as oposed to
other personalities leading to its unconditional access in
mddev_suspend() causing an oops.
Patch checks for mddev->thread in order to keep the
intention of aforementioned commit.
Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com>
---
drivers/md/md.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 194580f..d91920d 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -305,7 +305,7 @@ static blk_qc_t md_make_request(struct request_queue *q, struct bio *bio)
*/
void mddev_suspend(struct mddev *mddev)
{
- WARN_ON_ONCE(current == mddev->thread->tsk);
+ WARN_ON_ONCE(mddev->thread && current == mddev->thread->tsk);
if (mddev->suspended++)
return;
synchronize_rcu();
--
2.5.5
^ permalink raw reply related
* [PATCH] md: raid10: add prerequisite to run underneath dm-raid
From: heinzm @ 2016-05-09 15:50 UTC (permalink / raw)
To: linux-raid; +Cc: Heinz Mauelshagen
From: Heinz Mauelshagen <heinzm@redhat.com>
In case md runs underneath the dm-raid target, the mddev does not have
a request queue or gendisk, thus avoid accesses to it.
This patch adds two missing conditionals to the raid10 personality.
Signed-of-by: Heinz Mauelshagen <heinzm@redhat.com>
---
drivers/md/raid10.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index e3fd725..84e24e6 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -3782,8 +3782,10 @@ static int raid10_resize(struct mddev *mddev, sector_t sectors)
return ret;
}
md_set_array_sectors(mddev, size);
- set_capacity(mddev->gendisk, mddev->array_sectors);
- revalidate_disk(mddev->gendisk);
+ if (mddev->queue) {
+ set_capacity(mddev->gendisk, mddev->array_sectors);
+ revalidate_disk(mddev->gendisk);
+ }
if (sectors > mddev->dev_sectors &&
mddev->recovery_cp > oldsize) {
mddev->recovery_cp = oldsize;
@@ -4593,8 +4595,10 @@ static void raid10_finish_reshape(struct mddev *mddev)
set_bit(MD_RECOVERY_NEEDED, &mddev->recovery);
}
mddev->resync_max_sectors = size;
- set_capacity(mddev->gendisk, mddev->array_sectors);
- revalidate_disk(mddev->gendisk);
+ if (mddev->queue) {
+ set_capacity(mddev->gendisk, mddev->array_sectors);
+ revalidate_disk(mddev->gendisk);
+ }
} else {
int d;
for (d = conf->geo.raid_disks ;
--
2.5.5
^ permalink raw reply related
* [PATCH] md: raid5: add prerequisite to run underneath dm-raid
From: heinzm @ 2016-05-09 15:50 UTC (permalink / raw)
To: linux-raid; +Cc: Heinz Mauelshagen
From: Heinz Mauelshagen <heinzm@redhat.com>
In case md runs underneath the dm-raid target, the mddev does not have
a request queue or gendisk, thus avoid accesses.
This patch adds a missing conditional to the raid5 personality.
Signed-of-by: Heinz Mauelshagen <heinzm@redhat.com>
---
drivers/md/raid5.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 8ab8b65..ce79ce6 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -7574,8 +7574,10 @@ static void raid5_finish_reshape(struct mddev *mddev)
if (mddev->delta_disks > 0) {
md_set_array_sectors(mddev, raid5_size(mddev, 0, 0));
- set_capacity(mddev->gendisk, mddev->array_sectors);
- revalidate_disk(mddev->gendisk);
+ if (mddev->queue) {
+ set_capacity(mddev->gendisk, mddev->array_sectors);
+ revalidate_disk(mddev->gendisk);
+ }
} else {
int d;
spin_lock_irq(&conf->device_lock);
--
2.5.5
^ permalink raw reply related
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