* Re: [PATCH] mdadm: Check bitmap first when reshape raid1 to raid0
From: Xiao Ni @ 2015-10-27 6:24 UTC (permalink / raw)
To: Neil Brown; +Cc: Jes Sorensen, linux-raid
In-Reply-To: <877fm9dy5i.fsf@notabene.neil.brown.name>
----- Original Message -----
> From: "Neil Brown" <neilb@suse.de>
> To: "Xiao Ni" <xni@redhat.com>
> Cc: "Jes Sorensen" <jes.sorensen@redhat.com>, linux-raid@vger.kernel.org
> Sent: Tuesday, October 27, 2015 7:10:17 AM
> Subject: Re: [PATCH] mdadm: Check bitmap first when reshape raid1 to raid0
>
> On Mon, Oct 26 2015, Xiao Ni wrote:
>
> >>
> >
> > Thanks for printing out the mistake. I checked the nearby code and found
> > I missed close the cfd. Is this I missed? But I'm wondering that it doesn't
> > close it in the following code. Now it's just closed when it's failed to
> > reshape raid1/raid10 to raid0.
>
> That is a very sensible question to ask - thanks.
> After a quick look - it does seem very strange. That handling of 'cfd'
> and 'fd' seems quite odd.
>
> If you would like to work out what should happen and find a simple way
> to fix the code, that would be great. But I don't insist.
I'll try it and re-send a patch then.
>
> The patch below is quite acceptable as it is a simple solution to a
> simple problem and appear consistent with nearby code. So if you gave
> it a proper description, formatted it properly and posted it in a way
> that didn't mess up all the white space, I would very likely accept it.
>
> However:
> - maybe we should just remove the bitmap rather than complain if we
> find one. After all, we are removing other things (extra devices).
> A raid0 can never had a bitmap, so when converting to a raid0, it
> does make sense to remove the bitmap.
Yes, :) it's better to remove the bitmap than check it.
>
> - The test you used only checks for an internal bitmap, not an external
> one. External bitmaps are hardly ever used except by people who know
> exactly what they are doing, so I'm not too fussed about handling
> them perfectly, but testing for and removing an external bitmap
> might make sense.
>
> Thanks,
> NeilBrown
As you said, I haven't used external bitmaps before. I'll check how to handle
them and add it to the patch too.
Best Regards
Xiao
^ permalink raw reply
* Re: Converting 4 disk RAID10 to RAID5
From: Anugraha Sinha @ 2015-10-27 6:19 UTC (permalink / raw)
To: Adam Goryachev, Phil Turmel, linux-raid
In-Reply-To: <562EBD58.2040306@websitemanagers.com.au>
Dear Adam,
On 10/27/2015 8:55 AM, Adam Goryachev wrote:
>
> mdadm --grow --bitmap=none /dev/md0
> root@testraid:~# cat /proc/mdstat
> Personalities : [raid10] [raid0] [raid6] [raid5] [raid4]
> md0 : active raid5 vdf1[4] vdd1[3](S) vde1[2] vdc1[0]
> 2093056 blocks super 1.2 level 5, 512k chunk, algorithm 5 [3/3]
> [UUU]
>
> unused devices: <none>
>
> So, still 3 disk raid5 with one spare, but seems to be insync, so either
> it was really quick (possible since they are small drives) or it didn't
> need to do a sync??
>
> mdadm --grow --level=5 --raid-devices=4 /dev/md0
> mdadm: Need to backup 3072K of critical section..
>
> cat /proc/mdstat
> Personalities : [raid10] [raid0] [raid6] [raid5] [raid4]
> md0 : active raid5 vdf1[4] vdd1[3] vde1[2] vdc1[0]
> 2093056 blocks super 1.2 level 5, 512k chunk, algorithm 5 [4/4]
> [UUUU]
> resync=DELAYED
>
> unused devices: <none>
>
> OK, so now how to make it resync?
>
> Here I'm stuck...
> I've tried:
> mdadm --misc /dev/md0 --action=check
> mdadm --misc /dev/md0 --action=repair
>
> Nothing seems to be happening.
>
> BTW, I had the array mounted during my testing, as ideally that is what
> I will do with the live machine. Worst case scenario (on the live
> machine) I can afford to lose all the data, as it is only an extra
> backup of the other backup machine, but it would mean a few TB's of data
> across a slow WAN....
>
> Any suggestions on getting this to progress? Did I do something wrong?
>
> Thanks for the suggestion, it certainly looks promising so far.
Why dont you stop your array once and do something like this?
mdadm --stop /dev/md0
mdadm --assemble /dev/md0 --run --force --update=resync /dev/vdf1
/dev/vdd1 /dev/vde1 vdc1
This will restart your array with the required raid-level and also start
the resyncing process.
Regards
Anugraha
^ permalink raw reply
* Fwd: Replacing a RAID1 drive that has not failed.
From: Edward Kuns @ 2015-10-27 0:41 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <CACsGCyTM_J2+_oJm0rUsZvuF0AXXu6xX572F4HP+OGsjP_AvfQ@mail.gmail.com>
On Mon, Oct 26, 2015 at 6:00 PM, Doug Herr <gmane@wombatz.com> wrote:
> I think it might be time to replace one or both of my RAID 1 drives. [snip]
> I recently experimented with adding a third partition to my swap raid
> partition and that went very well, so I was thinking that this would
> provide a safer method to replace one drive compared to failing it and
> then replacing it.
> [snip]
I tried basically the procedure you described, based on Internet
research, to replace a working but suspect drive in a RAID. I ran
into problems. FWIW, my metadata format is 1.2. You can see the
thread at http://marc.info/?l=linux-raid&m=143668094907891&w=2
although the most pertinent EMail is the first response
http://marc.info/?l=linux-raid&m=143670871711935&w=2
I suppose it's possible that you might get different advice since
you're doing RAID 1 and I was doing RAID 5. I'm not an expert. I
just wanted to warn you that I ran into trouble basically doing what
you propose. The advice I got was that I shouldn't grow and shrink to
replace a disk. There's a --replace option for that. That'll remove
a few of your steps, simplify and speed up the process, and remove
risk. Hope this helps. Hopefully someone who knows a lot more than I
do will also speak up. Good luck.
Eddie
^ permalink raw reply
* Re: Converting 4 disk RAID10 to RAID5
From: Adam Goryachev @ 2015-10-26 23:55 UTC (permalink / raw)
To: Phil Turmel, linux-raid
In-Reply-To: <562E345D.5030206@turmel.org>
On 27/10/15 01:10, Phil Turmel wrote:
> Good morning Adam,
>
> On 10/25/2015 09:26 PM, Adam Goryachev wrote:
>> Hi all,
>>
>> I'm trying to convert a 4 disk RAID10 to a RAID5. Currently I have:
>> cat /proc/mdstat
>> Personalities : [raid10]
>> md0 : active raid10 sdd1[2] sdc1[1] sdb1[0] sde1[3]
>> 7813772288 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
>> bitmap: 0/59 pages [0KB], 65536KB chunk
> [trim /]
>
> Your plan looks reasonable, if a bit long. I've done similar before.
> Usually I add the new array to the LVM volume group of the original,
> then pvmove the contents to the new physical volume. Let's me stay
> online through the entire operation.
>
> Anyways, it seems you are missing an opportunity to convert in place,
> though. Consider setting up four small loop devices and test
> conversions from r10,n2 -n4 => r0 -n3 => r4 -n4 => r5 -n4 . I suspect
> you can get to your new raid5 without moving a bunch of data around.
This sounds interesting, I'm just messing around with a VM at the
moment, but I'm not sure I understand your shorthand?
Currently, I have raid10 with 4 devices
I can convert to raid0 with 2 devices
mdadm --grow --level=0 --raid-devices=2 /dev/md0
md0 : active raid0 vde1[2] vdc1[0]
2093056 blocks super 1.2 512k chunks
bitmap: 1/1 pages [4KB], 65536KB chunk
So then I tried to add the other two drives back:
mdadm --manage /dev/md0 --add /dev/vdd1
mdadm: add new device failed for /dev/vdd1 as 3: Invalid argument
That failed, raid0 doesn't allow spares, because there is nothing for
them to "do".
So I tried jumping to raid5:
mdadm --grow --level=5 --raid-devices=4 /dev/md0 /dev/vdd1 /dev/vdf1
mdadm: Must give -a/--add for devices to add: /dev/vdd1
OK, I was just guessing...
mdadm --grow --level=5 --raid-devices=4 /dev/md0 -a /dev/vdd1 -a /dev/vdf1
mdadm: level of /dev/md0 changed to raid5
mdadm: added /dev/vdd1
mdadm: added /dev/vdf1
mdadm: Need to backup 3072K of critical section..
mdadm: Cannot set device shape for /dev/md0
Bitmap must be removed before shape can be changed
unfreeze
Oh, alrighty... but wait, what did it actually do?
cat /proc/mdstat
Personalities : [raid10] [raid0] [raid6] [raid5] [raid4]
md0 : active raid5 vdf1[4] vdd1[3](S) vde1[2] vdc1[0]
2093056 blocks super 1.2 level 5, 512k chunk, algorithm 5 [3/3] [UUU]
bitmap: 1/1 pages [4KB], 65536KB chunk
Interesting, it has changed to a three disk RAID5 without removing the
bitmap, only adding the 4th disk seems to need that.
mdadm --grow --bitmap=none /dev/md0
root@testraid:~# cat /proc/mdstat
Personalities : [raid10] [raid0] [raid6] [raid5] [raid4]
md0 : active raid5 vdf1[4] vdd1[3](S) vde1[2] vdc1[0]
2093056 blocks super 1.2 level 5, 512k chunk, algorithm 5 [3/3] [UUU]
unused devices: <none>
So, still 3 disk raid5 with one spare, but seems to be insync, so either
it was really quick (possible since they are small drives) or it didn't
need to do a sync??
mdadm --grow --level=5 --raid-devices=4 /dev/md0
mdadm: Need to backup 3072K of critical section..
cat /proc/mdstat
Personalities : [raid10] [raid0] [raid6] [raid5] [raid4]
md0 : active raid5 vdf1[4] vdd1[3] vde1[2] vdc1[0]
2093056 blocks super 1.2 level 5, 512k chunk, algorithm 5 [4/4]
[UUUU]
resync=DELAYED
unused devices: <none>
OK, so now how to make it resync?
Here I'm stuck...
I've tried:
mdadm --misc /dev/md0 --action=check
mdadm --misc /dev/md0 --action=repair
Nothing seems to be happening.
BTW, I had the array mounted during my testing, as ideally that is what
I will do with the live machine. Worst case scenario (on the live
machine) I can afford to lose all the data, as it is only an extra
backup of the other backup machine, but it would mean a few TB's of data
across a slow WAN....
Any suggestions on getting this to progress? Did I do something wrong?
Thanks for the suggestion, it certainly looks promising so far.
PS test machine is running:
mdadm - v3.3.2 - 21st August 2014
Linux testraid 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux
Relevant sections from dmesg:
[ 582.456118] md/raid10:md0: Disk failure on vdd1, disabling device.
[ 582.456119] md/raid10:md0: Operation continuing on 3 devices.
[ 582.459135] RAID10 conf printout:
[ 582.459137] --- wd:3 rd:4
[ 582.459138] disk 0, wo:0, o:1, dev:vdc1
[ 582.459140] disk 1, wo:1, o:0, dev:vdd1
[ 582.459141] disk 2, wo:0, o:1, dev:vde1
[ 582.459142] disk 3, wo:0, o:1, dev:vdf1
[ 582.459144] RAID10 conf printout:
[ 582.459145] --- wd:3 rd:4
[ 582.459146] disk 0, wo:0, o:1, dev:vdc1
[ 582.459147] disk 2, wo:0, o:1, dev:vde1
[ 582.459148] disk 3, wo:0, o:1, dev:vdf1
[ 582.459174] md: unbind<vdd1>
[ 582.459178] md: export_rdev(vdd1)
[ 582.460851] md/raid10:md0: Disk failure on vdf1, disabling device.
[ 582.460852] md/raid10:md0: Operation continuing on 2 devices.
[ 582.463685] RAID10 conf printout:
[ 582.463687] --- wd:2 rd:4
[ 582.463689] disk 0, wo:0, o:1, dev:vdc1
[ 582.463700] disk 2, wo:0, o:1, dev:vde1
[ 582.463702] disk 3, wo:1, o:0, dev:vdf1
[ 582.463703] RAID10 conf printout:
[ 582.463704] --- wd:2 rd:4
[ 582.463705] disk 0, wo:0, o:1, dev:vdc1
[ 582.463706] disk 2, wo:0, o:1, dev:vde1
[ 582.463731] md: unbind<vdf1>
[ 582.463734] md: export_rdev(vdf1)
[ 661.433432] md: raid0 personality registered for level 0
[ 661.433775] md0: bitmaps are not supported for raid0
[ 1999.023095] md0: personality does not support diskops!
[ 1999.123016] md0: personality does not support diskops!
[ 1999.275905] md0: personality does not support diskops!
[ 1999.312123] md0: personality does not support diskops!
[ 2164.827683] async_tx: api initialized (async)
[ 2164.828731] xor: automatically using best checksumming function:
generic_sse
[ 2164.848017] generic_sse: 3623.000 MB/sec
[ 2164.848019] xor: using function: generic_sse (3623.000 MB/sec)
[ 2164.916020] raid6: int64x1 1743 MB/s
[ 2164.984015] raid6: int64x2 2248 MB/s
[ 2165.052028] raid6: int64x4 2537 MB/s
[ 2165.120021] raid6: int64x8 2143 MB/s
[ 2165.188010] raid6: sse2x1 6819 MB/s
[ 2165.256011] raid6: sse2x2 8521 MB/s
[ 2165.324014] raid6: sse2x4 9659 MB/s
[ 2165.324015] raid6: using algorithm sse2x4 (9659 MB/s)
[ 2165.328986] md: raid6 personality registered for level 6
[ 2165.328991] md: raid5 personality registered for level 5
[ 2165.328993] md: raid4 personality registered for level 4
[ 2165.329357] md/raid:md0: device vde1 operational as raid disk 1
[ 2165.329361] md/raid:md0: device vdc1 operational as raid disk 0
[ 2165.330125] md/raid:md0: allocated 3228kB
[ 2165.331574] md/raid:md0: raid level 5 active with 2 out of 3 devices,
algorithm 5
[ 2165.332646] RAID conf printout:
[ 2165.332648] --- level:5 rd:3 wd:2
[ 2165.332651] disk 0, o:1, dev:vdc1
[ 2165.332653] disk 1, o:1, dev:vde1
[ 2165.355069] md: bind<vdd1>
[ 2165.364753] md: bind<vdf1>
[ 2165.389506] md/raid0:md0: bad disk number -1 - aborting!
[ 2165.389849] md: md0: raid0 would not accept array
[ 2165.390051] RAID conf printout:
[ 2165.390053] --- level:5 rd:3 wd:2
[ 2165.390054] disk 0, o:1, dev:vdc1
[ 2165.390055] disk 1, o:1, dev:vde1
[ 2165.390056] disk 2, o:1, dev:vdf1
[ 2165.390061] RAID conf printout:
[ 2165.390062] --- level:5 rd:3 wd:2
[ 2165.390063] disk 0, o:1, dev:vdc1
[ 2165.390064] disk 1, o:1, dev:vde1
[ 2165.390065] disk 2, o:1, dev:vdf1
[ 2165.390960] md: recovery of RAID array md0
[ 2165.390962] md: minimum _guaranteed_ speed: 1000 KB/sec/disk.
[ 2165.390963] md: using maximum available idle IO bandwidth (but not
more than 200000 KB/sec) for recovery.
[ 2165.390973] md: using 128k window, over a total of 1046528k.
[ 2176.293108] md: md0: recovery done.
[ 2176.306088] RAID conf printout:
[ 2176.306091] --- level:5 rd:3 wd:3
[ 2176.306092] disk 0, o:1, dev:vdc1
[ 2176.306094] disk 1, o:1, dev:vde1
[ 2176.306095] disk 2, o:1, dev:vdf1
[ 2214.230914] RAID conf printout:
[ 2214.230920] --- level:5 rd:4 wd:4
[ 2214.230923] disk 0, o:1, dev:vdc1
[ 2214.230926] disk 1, o:1, dev:vde1
[ 2214.230929] disk 2, o:1, dev:vdf1
[ 2214.230931] disk 3, o:1, dev:vdd1
[ 2214.235161] md: reshape of RAID array md0
[ 2214.235164] md: minimum _guaranteed_ speed: 1000 KB/sec/disk.
[ 2214.235167] md: using maximum available idle IO bandwidth (but not
more than 200000 KB/sec) for reshape.
[ 2214.235186] md: using 128k window, over a total of 1046528k.
Regards,
Adam
--
Adam Goryachev Website Managers www.websitemanagers.com.au
^ permalink raw reply
* Re: [PATCH] mdadm: Check bitmap first when reshape raid1 to raid0
From: Neil Brown @ 2015-10-26 23:10 UTC (permalink / raw)
To: Xiao Ni; +Cc: Jes Sorensen, linux-raid
In-Reply-To: <1424506067.42737315.1445862310535.JavaMail.zimbra@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2545 bytes --]
On Mon, Oct 26 2015, Xiao Ni wrote:
>>
>
> Thanks for printing out the mistake. I checked the nearby code and found
> I missed close the cfd. Is this I missed? But I'm wondering that it doesn't
> close it in the following code. Now it's just closed when it's failed to
> reshape raid1/raid10 to raid0.
That is a very sensible question to ask - thanks.
After a quick look - it does seem very strange. That handling of 'cfd'
and 'fd' seems quite odd.
If you would like to work out what should happen and find a simple way
to fix the code, that would be great. But I don't insist.
The patch below is quite acceptable as it is a simple solution to a
simple problem and appear consistent with nearby code. So if you gave
it a proper description, formatted it properly and posted it in a way
that didn't mess up all the white space, I would very likely accept it.
However:
- maybe we should just remove the bitmap rather than complain if we
find one. After all, we are removing other things (extra devices).
A raid0 can never had a bitmap, so when converting to a raid0, it
does make sense to remove the bitmap.
- The test you used only checks for an internal bitmap, not an external
one. External bitmaps are hardly ever used except by people who know
exactly what they are doing, so I'm not too fussed about handling
them perfectly, but testing for and removing an external bitmap
might make sense.
Thanks,
NeilBrown
>
> Grow.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/Grow.c b/Grow.c
> index 80d7b22..d711884 100644
> --- a/Grow.c
> +++ b/Grow.c
> @@ -1898,6 +1898,15 @@ size_change_error:
> array.layout == ((1 << 8) + 2) && !(array.raid_disks & 1)) ||
> (s->level == 0 && array.level == 1 && sra)) {
> int err;
> +
> + if (array.state & (1<<MD_SB_BITMAP_PRESENT)) {
> + dprintf("Bitmap must be removed before level can be changed\n");
> + if (cfd > -1)
> + close(cfd);
> + rv = 1;
> + goto release;
> + }
> +
> err = remove_disks_for_takeover(st, sra, array.layout);
>
> Best Regards
> Xiao
>
> --
> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Replacing a RAID1 drive that has not failed.
From: Doug Herr @ 2015-10-26 23:00 UTC (permalink / raw)
To: linux-raid
I think it might be time to replace one or both of my RAID 1 drives.
They have been giving good service for six years. Both still have good
smartctl reports but I am ready to move one out to be used as a member of
my backup solution using old drives to hold rsync backups. I would thus
give my RAID a fresh disk before there is an actual failure.
I recently experimented with adding a third partition to my swap raid
partition and that went very well, so I was thinking that this would
provide a safer method to replace one drive compared to failing it and
then replacing it.
My test makes me think it might be as easy as:
1. Partition new drive (plugged in via external SATA dock)
Use: fdisk /dev/sdc
2. Add 3rd partition to each RAID.
Use: mdadm /dev/md4 --grow --raid-devices=3 --add /dev/sdc2
3. Wait for all the resyncs.
Use: watch cat /proc/mdstat
4. Fail out sda for each RAID.
Use: mdadm /dev/md4 --fail /dev/sda2
5. Drop back down to two disk.
Use: mdadm /dev/md4 --grow --raid-devices=2
6. Make the old partitions "safe".
Use: mdadm --zero-superblock /dev/sdc2
7. Power down and swap sdc into sda slot.
I only tested that with version 1.2 metadata, so I would be interested if
there is anything above that would not work with version 0.90. Also note
that I did my test using my swap partition but it seems like the
procedure should not care what sort of partitioning is used.
Below is info about my setup and how I tested to come up with the above
steps...
I am:
15:40-doug@wombat-~>uname -a
Linux wombat.wombatz.com 4.2.3-200.fc22.x86_64 #1 SMP Thu Oct 8 03:23:55
UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
15:40-doug@wombat-~>cat /etc/fedora-release
Fedora release 22 (Twenty Two)
15:40-doug@wombat-~>mdadm -V
mdadm - v3.3.2 - 21st August 2014
My RAID setup:
(I am not using RAID for /boot, instead I rsync /boot to /bootalt each
night. Otherwise everything is on RAID 1, including swap.)
15:23-doug@wombat-~/wombat-4/raid/current-2015-10-26>df -hT |grep -v
^tmpfs
Filesystem Type Size Used Avail Use% Mounted on
devtmpfs devtmpfs 4.4G 0 4.4G 0% /dev
/dev/md126 ext4 30G 11G 18G 39% /
/dev/sdb1 ext4 579M 126M 411M 24% /bootalt
/dev/md1 ext4 40G 18G 23G 44% /home
/dev/md123 ext4 422G 209G 192G 53% /data2
/dev/md125 ext4 422G 74G 327G 19% /data1
/dev/sda1 ext4 579M 126M 411M 24% /boot
15:09-doug@wombat-~>swapon -s
Filename Type Size Used
Priority
/dev/md4 partition 4946980 0 -1
(I am using UUID for /etc/mdadm.conf and in /etc/fstab so I did not
bother to "fix" the names when they got changed to md12x during Fedora
upgrades.)
15:19-doug@wombat-~>cat /proc/mdstat
Personalities : [raid1]
md123 : active raid1 sdb7[1] sda7[0]
448888128 blocks [2/2] [UU]
bitmap: 0/4 pages [0KB], 65536KB chunk
md125 : active raid1 sdb6[1] sda6[0]
448888128 blocks [2/2] [UU]
bitmap: 1/4 pages [4KB], 65536KB chunk
md1 : active raid1 sdb5[0] sda5[2]
41952620 blocks super 1.2 [2/2] [UU]
bitmap: 1/1 pages [4KB], 65536KB chunk
md126 : active raid1 sdb3[0] sda3[1]
31463232 blocks [2/2] [UU]
bitmap: 1/1 pages [4KB], 65536KB chunk
md4 : active raid1 sdb2[2] sda2[3]
4946984 blocks super 1.2 [2/2] [UU]
unused devices: <none>
Notes from the test I did using a partion on a older and smaller drive...
[root@wombat Documents]# mdadm --detail /dev/md4
/dev/md4:
Version : 1.2
Creation Time : Sat Mar 24 16:53:28 2012
Raid Level : raid1
Array Size : 4946984 (4.72 GiB 5.07 GB)
Used Dev Size : 4946984 (4.72 GiB 5.07 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Fri Oct 23 10:55:06 2015
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Name : wombat.wombatz.com:4 (local to host wombat.wombatz.com)
UUID : 2382da1b:c77c04c7:9e4f955c:9450c809
Events : 541
Number Major Minor RaidDevice State
3 8 2 0 active sync /dev/sda2
2 8 18 1 active sync /dev/sdb2
[root@wombat Documents]# fdisk /dev/sdc
[snip]
[root@wombat doug]# mdadm /dev/md4 --grow --raid-devices=3 --add /dev/sdc2
mdadm: added /dev/sdc2
unfreeze
[root@wombat Documents]# cat /proc/mdstat
[snip]
md4 : active raid1 sdc2[4] sdb2[2] sda2[3]
4946984 blocks super 1.2 [3/2] [UU_]
[=======>.............] recovery = 39.2% (1941056/4946984)
finish=0.6min speed=71890K/sec
Soon it showed:
md4 : active raid1 sdc2[4] sdb2[2] sda2[3]
4946984 blocks super 1.2 [3/3] [UUU]
And now:
[root@wombat Documents]# mdadm --detail /dev/md4
/dev/md4:
Version : 1.2
Creation Time : Sat Mar 24 16:53:28 2012
Raid Level : raid1
Array Size : 4946984 (4.72 GiB 5.07 GB)
Used Dev Size : 4946984 (4.72 GiB 5.07 GB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent
Update Time : Sat Oct 24 12:57:39 2015
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Name : wombat.wombatz.com:4 (local to host wombat.wombatz.com)
UUID : 2382da1b:c77c04c7:9e4f955c:9450c809
Events : 562
Number Major Minor RaidDevice State
3 8 2 0 active sync /dev/sda2
2 8 18 1 active sync /dev/sdb2
4 8 33 2 active sync /dev/sdc2
Now try to remove it:
[root@wombat doug]# mdadm /dev/md4 --fail /dev/sdc2
mdadm: set /dev/sdc2 faulty in /dev/md4
[root@wombat doug]# mdadm /dev/md4 --grow --raid-devices=2
raid_disks for /dev/md4 set to 2
unfreeze
Seems good:
md4 : active raid1 sdc2[4](F) sdb2[2] sda2[3]
4946984 blocks super 1.2 [2/2] [UU]
Just to be safe:
mdadm --zero-superblock /dev/sdc2
--
Doug Herr
^ permalink raw reply
* Re: Remove inactive array created by open
From: Neil Brown @ 2015-10-26 22:10 UTC (permalink / raw)
To: Simon Guinot; +Cc: linux-raid, Remi Reroller, Vincent Donnefort, Yoann Sculo
In-Reply-To: <20151026211252.GC4665@kw.sim.vm.gnt>
[-- Attachment #1: Type: text/plain, Size: 4323 bytes --]
On Tue, Oct 27 2015, Simon Guinot wrote:
> On Fri, Oct 23, 2015 at 08:23:38AM +1100, Neil Brown wrote:
>> Simon Guinot <simon.guinot@sequanux.org> writes:
>>
>> > Hi Neil,
>> >
>> > I'd like to have your advice about destroying an array created by open
>> > at close time if not configured, rather than waiting for a ioctl or a
>> > sysfs configuration. This would allow to get rid of the inactive md
>> > devices created by an "accidental" open.
>> >
>> > On the Linux distribution embedded in LaCie NAS, we are able to
>> > observe the following scenario:
>> >
>> > 1. A RAID array is stopped with a command such as mdadm --stop /dev/mdx.
>> > 2. The node /dev/mdx is still available because not removed by mdadm at
>> > stop.
>> > 3. /dev/mdx is opened by a process such as udev or mdadm --monitor.
>> > 4. An inactive RAID array mdx is created and a "add" uevent is
>> > broadcasted to userland. It is let to userland to understand that
>> > this event must be discarded.
>> >
>> > You have to admit that this behaviour is at best awkward :)
>>
>> No argument there.
>>
>>
>> >
>> > I read the commit d3374825ce57
>> > "md: make devices disappear when they are no longer needed" in which
>> > you express some concerns about an infinite loop due to udev always
>> > opening newly created devices. Is that still actual ?
>> >
>> > In your opinion, how could we get rid of an inactive RAID array created
>> > by open ? Maybe we could switch the hold_active flag from UNTIL_IOCTL to
>> > 0 after some delay (enough to prevent udev from looping) ? In addition,
>> > maybe we could remove the device node from mdadm --stop ? Or maybe
>> > something else :)
>> >
>> > If you are interested by any of this solutions or one of yours, I'll
>> > be happy to work on it.
>>
>> By far the best solution here is to used named md devices. These are
>> relatively recent and I wouldn't be surprised if you weren't aware of
>> them.
>>
>> md devices 9,0 to 9,511 (those are major,minor numbers) are "numeric" md
>> devices. They have in-kernel names md%d which appear in /proc/mdstat
>> and /sys/block/
>>
>> If you create a block-special-device node with these numbers, that will
>> create the md device if it doesn't already exist.
>>
>> md devices 9,512 to 9,$BIGNUM are "named" md devices. These have
>> in-kernel names like md_whatever-you-like.
>> If you create a block-special-device with device number 9,512 and try to
>> open it you will get -ENODEV.
>> To create these you
>> echo whatever-you-like > /sys/module/md_mod/parameters/new_array
>>
>> A number 512 or greater will be allocated as the minor number.
>>
>> These arrays behave as you would want them to. They are only created
>> when explicitly requested and they disappear when stopped.
>>
>> mdadm will create this sort of array if you add
>> CREATE names=yes
>> to mdadm.conf and don't use numeric device names.
>> i.e. if you ask for /dev/md0, you will still get 9,0.
>> But if you ask for /dev/md/home, you will get 9,512 where as
>> with names=no (the default) you would probably get 9,127.
>
> Thanks for describing the usage of the named md devices. We will look
> to convert our userland from numeric to named md devices.
I think that is the best approach if you can make it work
>
>>
>> A timeout for dropping idle numeric md devices might make sense but it
>> would need to be several seconds at least as udev can sometimes get very
>> backlogged and would wouldn't want to add to that. Would 5 minutes be
>> soon enough to meet your need?
>
> No unfortunately, this will not. In our case, I think we need to
> remove the inactive numeric md device at close or quickly after.
>
> Considering that for a numeric md device we need to add the gendisk at
> probe and that we can't destroy it at close if inactive (due to the udev
> issue), then I don't think there is a solution to our problem. But I was
> kind of hoping you had an idea :)
The only thing I can think of is suppressing the ADD uevent until
something happens which would make the device more permanent. However I
suspect that would require and ugly hack so I have serious doubts about
it being accepted upstream (I'm not sure I would accept it :-)
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: Remove inactive array created by open
From: Simon Guinot @ 2015-10-26 21:12 UTC (permalink / raw)
To: Neil Brown; +Cc: linux-raid, Remi Reroller, Vincent Donnefort, Yoann Sculo
In-Reply-To: <87vb9yzjfp.fsf@notabene.neil.brown.name>
[-- Attachment #1: Type: text/plain, Size: 3848 bytes --]
On Fri, Oct 23, 2015 at 08:23:38AM +1100, Neil Brown wrote:
> Simon Guinot <simon.guinot@sequanux.org> writes:
>
> > Hi Neil,
> >
> > I'd like to have your advice about destroying an array created by open
> > at close time if not configured, rather than waiting for a ioctl or a
> > sysfs configuration. This would allow to get rid of the inactive md
> > devices created by an "accidental" open.
> >
> > On the Linux distribution embedded in LaCie NAS, we are able to
> > observe the following scenario:
> >
> > 1. A RAID array is stopped with a command such as mdadm --stop /dev/mdx.
> > 2. The node /dev/mdx is still available because not removed by mdadm at
> > stop.
> > 3. /dev/mdx is opened by a process such as udev or mdadm --monitor.
> > 4. An inactive RAID array mdx is created and a "add" uevent is
> > broadcasted to userland. It is let to userland to understand that
> > this event must be discarded.
> >
> > You have to admit that this behaviour is at best awkward :)
>
> No argument there.
>
>
> >
> > I read the commit d3374825ce57
> > "md: make devices disappear when they are no longer needed" in which
> > you express some concerns about an infinite loop due to udev always
> > opening newly created devices. Is that still actual ?
> >
> > In your opinion, how could we get rid of an inactive RAID array created
> > by open ? Maybe we could switch the hold_active flag from UNTIL_IOCTL to
> > 0 after some delay (enough to prevent udev from looping) ? In addition,
> > maybe we could remove the device node from mdadm --stop ? Or maybe
> > something else :)
> >
> > If you are interested by any of this solutions or one of yours, I'll
> > be happy to work on it.
>
> By far the best solution here is to used named md devices. These are
> relatively recent and I wouldn't be surprised if you weren't aware of
> them.
>
> md devices 9,0 to 9,511 (those are major,minor numbers) are "numeric" md
> devices. They have in-kernel names md%d which appear in /proc/mdstat
> and /sys/block/
>
> If you create a block-special-device node with these numbers, that will
> create the md device if it doesn't already exist.
>
> md devices 9,512 to 9,$BIGNUM are "named" md devices. These have
> in-kernel names like md_whatever-you-like.
> If you create a block-special-device with device number 9,512 and try to
> open it you will get -ENODEV.
> To create these you
> echo whatever-you-like > /sys/module/md_mod/parameters/new_array
>
> A number 512 or greater will be allocated as the minor number.
>
> These arrays behave as you would want them to. They are only created
> when explicitly requested and they disappear when stopped.
>
> mdadm will create this sort of array if you add
> CREATE names=yes
> to mdadm.conf and don't use numeric device names.
> i.e. if you ask for /dev/md0, you will still get 9,0.
> But if you ask for /dev/md/home, you will get 9,512 where as
> with names=no (the default) you would probably get 9,127.
Thanks for describing the usage of the named md devices. We will look
to convert our userland from numeric to named md devices.
>
> A timeout for dropping idle numeric md devices might make sense but it
> would need to be several seconds at least as udev can sometimes get very
> backlogged and would wouldn't want to add to that. Would 5 minutes be
> soon enough to meet your need?
No unfortunately, this will not. In our case, I think we need to
remove the inactive numeric md device at close or quickly after.
Considering that for a numeric md device we need to add the gendisk at
probe and that we can't destroy it at close if inactive (due to the udev
issue), then I don't think there is a solution to our problem. But I was
kind of hoping you had an idea :)
Thanks.
Simon
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: Fwd: mdadm format for manual destriping
From: Phil Turmel @ 2015-10-26 19:13 UTC (permalink / raw)
To: Marek, Linux-RAID
In-Reply-To: <CA+sqOsZzk3kTPK-rkvyDyhZCwBot_bOaVT8XbW5-h8c2YVn1Mw@mail.gmail.com>
Hi Marek,
{ Top-posting fixed. Please don't do that. }
On 10/26/2015 02:09 PM, Marek wrote:
> On Saturday, October 24, 2015, Marek <mlf.conv@gmail.com> wrote:
>> is there a documentation available on how mdadm stores data? E.g.
Yes, the man pages. Try "man md" and "man mdadm" in a console. This
documentation is provide by the kernel team and, other than the source
code itself, is expected to be definitive.
>> 1. super-block
The location of the superblock is described in "man md". The precise
content of the superblock is only detailed in the source code.
>> 2. offset of first block on each drive
Zero for metadata versions 0.90 and 1.0. Configurable for metadata
versions 1.1 and 1.2. See the --data-offset option in "man mdadm".
>> 3. whether mdadm stores blocks as raw data or stores some kind of
>> metadata associated with each block e.g. disk 1 -> data_block1
>> immidiatelly followed by data_block 5 or
>> metadata_for_block_1 | data_block 1 | metadata_for_block_5 | data_block 5 |
No metadata per block.
>> 4. how and where mdadm stores its backup superblock
None, although each device has one.
>> 5. what klind of XOR algorithm is used by mdadm
Straight parity for raid4, raid5, and the 'P' blocks of raid6. Galois
field arithmetic for the 'Q' blocks of raid6.
https://www.kernel.org/pub/linux/kernel/people/hpa/raid6.pdf
[trim /]
> Does the first block start immediately after 258 bytes?
No.
> Also question 3,4,5
See above and in the man pages.
HTH,
Phil
^ permalink raw reply
* Fwd: mdadm format for manual destriping
From: Marek @ 2015-10-26 18:09 UTC (permalink / raw)
To: Linux-RAID
In-Reply-To: <CA+sqOsY5UwwGbnHVQ+ctBGKo1FEOWWbAqWBmYCqo4Z6tVTL4Kw@mail.gmail.com>
I have found the following link which answers question 1.
But there's more stuff that's seems undocumented
https://raid.wiki.kernel.org/index.php/RAID_superblock_formats
Question 2
Does the superblock of size 256+2 start at 0?
Does the first block start immediately after 258 bytes?
Also question 3,4,5
Marek
On Saturday, October 24, 2015, Marek <mlf.conv@gmail.com> wrote:
>
> Hi,
>
> is there a documentation available on how mdadm stores data? E.g.
> 1. super-block
> 2. offset of first block on each drive
> 3. whether mdadm stores blocks as raw data or stores some kind of
> metadata associated with each block e.g. disk 1 -> data_block1
> immidiatelly followed by data_block 5 or
> metadata_for_block_1 | data_block 1 | metadata_for_block_5 | data_block 5 |
> 4. how and where mdadm stores its backup superblock
> 5. what klind of XOR algorithm is used by mdadm
>
> thanks,
>
> Marek
^ permalink raw reply
* Re: Converting 4 disk RAID10 to RAID5
From: Phil Turmel @ 2015-10-26 14:10 UTC (permalink / raw)
To: Adam Goryachev, linux-raid
In-Reply-To: <562D8142.80507@websitemanagers.com.au>
Good morning Adam,
On 10/25/2015 09:26 PM, Adam Goryachev wrote:
> Hi all,
>
> I'm trying to convert a 4 disk RAID10 to a RAID5. Currently I have:
> cat /proc/mdstat
> Personalities : [raid10]
> md0 : active raid10 sdd1[2] sdc1[1] sdb1[0] sde1[3]
> 7813772288 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
> bitmap: 0/59 pages [0KB], 65536KB chunk
[trim /]
Your plan looks reasonable, if a bit long. I've done similar before.
Usually I add the new array to the LVM volume group of the original,
then pvmove the contents to the new physical volume. Let's me stay
online through the entire operation.
Anyways, it seems you are missing an opportunity to convert in place,
though. Consider setting up four small loop devices and test
conversions from r10,n2 -n4 => r0 -n3 => r4 -n4 => r5 -n4 . I suspect
you can get to your new raid5 without moving a bunch of data around.
Phil
^ permalink raw reply
* Re: Converting 4 disk RAID10 to RAID5
From: Anugraha Sinha @ 2015-10-26 14:09 UTC (permalink / raw)
To: Adam Goryachev, linux-raid
In-Reply-To: <562D8142.80507@websitemanagers.com.au>
Dear Adam
On 10/26/2015 10:26 AM, Adam Goryachev wrote:
> 1) fail two drives from the array:
> mdadm --manage /dev/md0 --fail /dev/sdb1
> mdadm --manage /dev/md0 --remove /dev/sdb1
> mdadm --manage /dev/md0 --fail /dev/sdd1
> mdadm --manage /dev/md0 --remove /dev/sdd1
> mdadm --misc --zero-superblock /dev/sdb1
> mdadm --misc --zero-superblock /dev/sdd1
>
> It seems that RAID10 device number is in order:
> sdb1 device0
> sdc1 device1
> sdd1 device2
> sde1 device3
> Therefore, I can fail device 0 (sdb1) and device 2 (sdd1) without losing
> any data.
>
> 2) create a 3 disk RAID5 with one disk missing.
> mdadm --create /dev/md1 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdd1
> missing
>
> 3) Then copy all of the existing data across
> unmount partitions, stop LVM/etc
> dd bs=16M if=/dev/md0 of=/dev/md1
I dont know why this would be necessary.
>
> 4) Finally, stop the md0, and add the two devices to the new raid5, and
> then grow the array to use the space on the 4th drive.
> mdadm --manage --stop /dev/md0
> mdadm --misc --zero-superblock /dev/sdc1
> mdadm --manage /dev/md1 --add /dev/sdc1
> mdadm --misc --zero-superblock /dev/sde1
> mdadm --manage /dev/md1 --add /dev/sde1
> mdadm --grow /dev/md1 --raid-devices=4
>
> 5) Add the space to my LVM
> pvresize /dev/md1
>
> 6) Start up LVM, mount LV's, etc
I tried your method on a local system, and it seemed to worked.
The reason why I said that dd would'nt be necessary, as it is raid
syncing would work. You just need to be careful that you should not
start doing remove/add and other changing aspects of raid till the time
syncing is going on.
Finally when you grow your raid in RAID5 also syncing would happen.
Regards
Anugraha Sinha
^ permalink raw reply
* Re: [PATCH] mdadm: Check bitmap first when reshape raid1 to raid0
From: Xiao Ni @ 2015-10-26 12:25 UTC (permalink / raw)
To: Neil Brown; +Cc: Jes Sorensen, linux-raid
In-Reply-To: <877fmag0mn.fsf@notabene.neil.brown.name>
----- Original Message -----
> From: "Neil Brown" <neilb@suse.de>
> To: "Xiao Ni" <xni@redhat.com>
> Cc: "Jes Sorensen" <jes.sorensen@redhat.com>, linux-raid@vger.kernel.org
> Sent: Monday, October 26, 2015 4:21:36 AM
> Subject: Re: Fwd: [PATCH] mdadm: Check bitmap first when reshape raid1 to raid0
>
> Xiao Ni <xni@redhat.com> writes:
>
> > Hi Neil
> >
> > I encountered one problem. When reshape one raid1 with bitmap to raid0,
> > it'll
> > lose legs.
> >
> > I sent the patch by git-send-email, but I can't see the mail in linux-raid.
> > So
> > I forward it again. And add signed-off-by line.
> >
> > Best Regards
> > Xiao
> >
> > ----- Forwarded Message -----
> > From: "Xiao Ni" <xni@redhat.com>
> > To: xni@redhat.com
> > Sent: Sunday, October 25, 2015 1:36:02 PM
> > Subject: [PATCH] mdadm: Check bitmap first when reshape raid1 to raid0
> >
> > One raid1 with bitmap is composed by 4 disks. It'll fail when rashape to
> > raid0
> > and lose 3 disks. It should check bitmap first when reshape raid1 to raid0.
> >
> > Signed-off-by: Xiao Ni <xni@redhat.com>
> > ---
> > Grow.c | 9 ++++++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/Grow.c b/Grow.c
> > index 80d7b22..5e9b0bb 100644
> > --- a/Grow.c
> > +++ b/Grow.c
> > @@ -1898,6 +1898,12 @@ size_change_error:
> > array.layout == ((1 << 8) + 2) && !(array.raid_disks & 1)) ||
> > (s->level == 0 && array.level == 1 && sra)) {
> > int err;
> > +
> > + if (array.state & (1<<MD_SB_BITMAP_PRESENT)) {
> > + cont_err("Bitmap must be removed before level can be changed\n");
> > + rv = 1;
> > + goto release;
> > + }
> > err = remove_disks_for_takeover(st, sra, array.layout);
> > if (err) {
> > dprintf("Array cannot be reshaped\n");
> > @@ -2706,9 +2712,6 @@ static int impose_level(int fd, int level, char
> > *devname, int verbose)
> > err = errno;
> > pr_err("%s: could not set level to %s\n",
> > devname, c);
> > - if (err == EBUSY &&
> > - (array.state & (1<<MD_SB_BITMAP_PRESENT)))
> > - cont_err("Bitmap must be removed before level can be changed\n");
> > return err;
> > }
> > if (verbose >= 0)
> > --
>
> You appear to have identified a problem that needs fixing, but the
> patch is fairly obviously wrong.
>
> You've removed a test and error message that could apply to any level
> change, and added a test and error message that only applies to some
> specific level changes.
> Why does that error message no longer apply to all the other possible
> level changes?
>
> The test that you have added is mostly OK ... but you missed something.
> Look around and similar nearby code.
> The test you removed certainly should stay.
>
> NeilBrown
>
Thanks for printing out the mistake. I checked the nearby code and found
I missed close the cfd. Is this I missed? But I'm wondering that it doesn't
close it in the following code. Now it's just closed when it's failed to
reshape raid1/raid10 to raid0.
Grow.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Grow.c b/Grow.c
index 80d7b22..d711884 100644
--- a/Grow.c
+++ b/Grow.c
@@ -1898,6 +1898,15 @@ size_change_error:
array.layout == ((1 << 8) + 2) && !(array.raid_disks & 1)) ||
(s->level == 0 && array.level == 1 && sra)) {
int err;
+
+ if (array.state & (1<<MD_SB_BITMAP_PRESENT)) {
+ dprintf("Bitmap must be removed before level can be changed\n");
+ if (cfd > -1)
+ close(cfd);
+ rv = 1;
+ goto release;
+ }
+
err = remove_disks_for_takeover(st, sra, array.layout);
Best Regards
Xiao
^ permalink raw reply related
* KREDIT 1%
From: ', KREDIT, '' @ 2015-10-26 9:54 UTC (permalink / raw)
To: Recipients
Hallo
Sie braucht einen Kredit, um Ihre dept zahlen oder starten jedes Unternehmen ?? Wir bieten alle Arten von Darlehen zu 1% Zins, wenn ja, mailen Sie uns mit Ihrem zurück
Voller Name:
Darlehensbetrag benötigt:
Dauer:
Telefonnummer:
Land:
--
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
From: ', KREDIT, '' @ 2015-10-26 9:52 UTC (permalink / raw)
To: Recipients
Hallo mein lieber Freund,
Ich schreibe diese Mail an Sie mit schweren Tränen in den Augen und
großen Trauer in meinem Herzen, mein Name ist Vera Hollin Kvan, und
ich wende mich an Sie aus meinem Land Indien Ich möchte Ihnen
sagen,weil ich nicht über keine andere Wahl, als zu sagen, wie ich war
gerührt, um zu öffnen, Sie heiratete ich Herrn Hollin Kvan, die mit
Tunesien Botschaft arbeitete in Madrid Spanien für neun Jahre, bevor
er im Jahr 2005.We waren gestorben seit elf Jahren verheiratet, ohne
ein Kind.
Er starb nach kurzer Krankheit, die nur fünf Tage dauerte. Da seinem
Tod Ich beschloss, nicht zu heiraten, als mein verstorbener Mann noch
am Leben war er hinterlegt die Summe von US $ 4,850m (vier Millionen
achthundertfünfzig Tausend US-Dollar) in einer Bank hier in Indien
Neu-Delhi die Hauptstadt von Neu-Delhi Indien Gegenwärtig dieses Geld
ist immer noch in der Bank.
Er machte diese Geld für die Ausfuhr von Gold aus Madrid Spanien
verfügbar Bergbau Kürzlich sagte mir mein Arzt, dass ich nicht zum
letzten Zeitraum von sieben Monaten durch Krebs Problem. Die eine, die
mich stört die meisten ist mein Schlaganfall sickness.Having bekannten
meinen Zustand Ich beschloss, die Hand Sie über dieses Geld, um Pflege
der weniger privilegierten Menschen zu nehmen, die Sie wird dieses
Geld nutzen, wie ich bin dabei, hier zu unterrichten.
Ich möchte, dass 30 Prozent der gesamten Geld für Ihren persönlichen
Gebrauch zu nehmen Während 70% der Geld wird für wohltätige Zwecke
gehen, Menschen auf der Straße und hilft dem Waisenhaus. Ich wuchs als
Waise und ich habe keine Körper als meine Familienmitglied, nur um am
Ende eavour, dass das Haus Gottes ist
gehalten.
Tue dies so, dass Gott meine Sünden zu vergeben und zu akzeptieren
meine Seele, weil diese Krankheiten haben mir so viel gelitten. Sobald
Ich Ihre Antwort erhalten werde ich hier in Ihnen den Kontakt der Bank
Delhi Indien, und ich werde auch den Bankdirektor anweisen, Sie
erteilen eine Autorität Brief, den Sie belegen die vorliegenden
Nutznießer der Geld auf der Bank, das ist, wenn Sie mich versichern,
dass Sie handeln entsprechend wie ich hier angegeben.
In der Hoffnung auf Ihre Antwort erhalten
Von Vera Hollin kvan
--
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
* [GIT PULL REQUEST] md fixes for 4.3-rc
From: Neil Brown @ 2015-10-26 6:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux-RAID, Jes Sorensen, Heinz Mauelshagen, Nate Dailey
[-- Attachment #1: Type: text/plain, Size: 1689 bytes --]
Hi Linus,
I meant to get this to you before -rc7, but what with all the travel
plans..
anyway, here are a few of bug-fixes worthy of 4.3.
Thanks,
NeilBrown
The following changes since commit 7379047d5585187d1288486d4627873170d0005a:
Linux 4.3-rc6 (2015-10-18 16:08:42 -0700)
are available in the git repository at:
git://neil.brown.name/md/ tags/md/4.3-rc6-fixes
for you to fetch changes up to 8bce6d35b308d73cdb2ee273c95d711a55be688c:
md/raid10: fix the 'new' raid10 layout to work correctly. (2015-10-24 16:24:25 +1100)
----------------------------------------------------------------
Some raid1/raid10 fixes.
Two fixes for bugs that are in both raid1 and raid10.
Both related to bad-block-lists and at least one needs
to be back ported to 3.1.
Also a revision for the "new" layout in raid10.
This "new" code (which aims to improve robustness) actually
reduces robustness in some cases.
It probably isn't in use at all as not public user-space code
makes use of these new layouts.
However just in case someone has their own code, it would be
good to get the WARNing out for them sooner.
----------------------------------------------------------------
Jes Sorensen (2):
md/raid1: submit_bio_wait() returns 0 on success
md/raid10: submit_bio_wait() returns 0 on success
NeilBrown (3):
md/raid1: don't clear bitmap bit when bad-block-list write fails.
md/raid10: don't clear bitmap bit when bad-block-list write fails.
md/raid10: fix the 'new' raid10 layout to work correctly.
drivers/md/raid1.c | 13 +++++++++----
drivers/md/raid10.c | 39 ++++++++++++++++++++++++++++++++-------
2 files changed, 41 insertions(+), 11 deletions(-)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Converting 4 disk RAID10 to RAID5
From: Adam Goryachev @ 2015-10-26 1:26 UTC (permalink / raw)
To: linux-raid
Hi all,
I'm trying to convert a 4 disk RAID10 to a RAID5. Currently I have:
cat /proc/mdstat
Personalities : [raid10]
md0 : active raid10 sdd1[2] sdc1[1] sdb1[0] sde1[3]
7813772288 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
bitmap: 0/59 pages [0KB], 65536KB chunk
Disks are:
Model Family: Western Digital Red (AF)
Device Model: WDC WD40EFRX-68WT0N0
My plan was to see if mdadm can do this directly, but it seems that it
can't:
mdadm --grow --level=5 /dev/md0
mdadm: RAID10 can only be changed to RAID0
unfreeze
(Please let me know if a newer version of kernel/mdadm can do this):
mdadm - v3.3.2 - 21st August 2014
Linux dr 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u2 (2015-07-17)
x86_64 GNU/Linux
So, my other idea is:
1) fail two drives from the array:
mdadm --manage /dev/md0 --fail /dev/sdb1
mdadm --manage /dev/md0 --remove /dev/sdb1
mdadm --manage /dev/md0 --fail /dev/sdd1
mdadm --manage /dev/md0 --remove /dev/sdd1
mdadm --misc --zero-superblock /dev/sdb1
mdadm --misc --zero-superblock /dev/sdd1
It seems that RAID10 device number is in order:
sdb1 device0
sdc1 device1
sdd1 device2
sde1 device3
Therefore, I can fail device 0 (sdb1) and device 2 (sdd1) without losing
any data.
2) create a 3 disk RAID5 with one disk missing.
mdadm --create /dev/md1 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdd1
missing
3) Then copy all of the existing data across
unmount partitions, stop LVM/etc
dd bs=16M if=/dev/md0 of=/dev/md1
4) Finally, stop the md0, and add the two devices to the new raid5, and
then grow the array to use the space on the 4th drive.
mdadm --manage --stop /dev/md0
mdadm --misc --zero-superblock /dev/sdc1
mdadm --manage /dev/md1 --add /dev/sdc1
mdadm --misc --zero-superblock /dev/sde1
mdadm --manage /dev/md1 --add /dev/sde1
mdadm --grow /dev/md1 --raid-devices=4
5) Add the space to my LVM
pvresize /dev/md1
6) Start up LVM, mount LV's, etc
Does the above sound reasonable? Any other suggestions which would be
better/less dangerous?
Some more detailed info on my existing array:
mdadm --misc --examine /dev/sdb1
/dev/sdb1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 40a09d68:b217d8ec:c90a61a7:ab35f26e
Name : backuppc:0
Creation Time : Sat Mar 21 01:19:22 2015
Raid Level : raid10
Raid Devices : 4
Avail Dev Size : 7813772943 (3725.90 GiB 4000.65 GB)
Array Size : 7813772288 (7451.79 GiB 8001.30 GB)
Used Dev Size : 7813772288 (3725.90 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=655 sectors
State : clean
Device UUID : 4b9d99c9:2a930721:e8052eb2:65121805
Internal Bitmap : 8 sectors from superblock
Update Time : Mon Oct 26 12:00:12 2015
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : d435138c - correct
Events : 27019
Layout : near=2
Chunk Size : 512K
Device Role : Active device 0
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdc1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 40a09d68:b217d8ec:c90a61a7:ab35f26e
Name : backuppc:0
Creation Time : Sat Mar 21 01:19:22 2015
Raid Level : raid10
Raid Devices : 4
Avail Dev Size : 7813772943 (3725.90 GiB 4000.65 GB)
Array Size : 7813772288 (7451.79 GiB 8001.30 GB)
Used Dev Size : 7813772288 (3725.90 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=655 sectors
State : clean
Device UUID : a8486bf8:b0e7c4d7:8e09bdc6:1a5f409b
Internal Bitmap : 8 sectors from superblock
Update Time : Mon Oct 26 12:00:12 2015
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 647b63cd - correct
Events : 27019
Layout : near=2
Chunk Size : 512K
Device Role : Active device 1
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdd1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 40a09d68:b217d8ec:c90a61a7:ab35f26e
Name : backuppc:0
Creation Time : Sat Mar 21 01:19:22 2015
Raid Level : raid10
Raid Devices : 4
Avail Dev Size : 7813772943 (3725.90 GiB 4000.65 GB)
Array Size : 7813772288 (7451.79 GiB 8001.30 GB)
Used Dev Size : 7813772288 (3725.90 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=655 sectors
State : clean
Device UUID : c46cdf6f:19f0ea49:1f5cc79a:1df744d7
Internal Bitmap : 8 sectors from superblock
Update Time : Mon Oct 26 12:00:12 2015
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 5e247ae6 - correct
Events : 27019
Layout : near=2
Chunk Size : 512K
Device Role : Active device 2
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sde1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 40a09d68:b217d8ec:c90a61a7:ab35f26e
Name : backuppc:0
Creation Time : Sat Mar 21 01:19:22 2015
Raid Level : raid10
Raid Devices : 4
Avail Dev Size : 7813772943 (3725.90 GiB 4000.65 GB)
Array Size : 7813772288 (7451.79 GiB 8001.30 GB)
Used Dev Size : 7813772288 (3725.90 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=655 sectors
State : clean
Device UUID : b9639e06:b48b15f4:8403c056:ea9bdcd3
Internal Bitmap : 8 sectors from superblock
Update Time : Mon Oct 26 12:00:12 2015
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 579e59a9 - correct
Events : 27019
Layout : near=2
Chunk Size : 512K
Device Role : Active device 3
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
--
Adam Goryachev Website Managers www.websitemanagers.com.au
^ permalink raw reply
* Re: 2nd Faulty drive while rebuilding array on RAID5
From: Phil Turmel @ 2015-10-25 23:38 UTC (permalink / raw)
To: Guillaume ALLEE, linux-raid
In-Reply-To: <CABEdK7w7zjjEXXenWRK0BSziekBGhkni50y0j3t=rW2AxNkkqQ@mail.gmail.com>
Hi Guillaume,
On 10/24/2015 06:27 PM, Guillaume ALLEE wrote:
> Hi all,
>
> Context:
> On my RAID5 sdc was faulty. I bought a new HD, format it and add it to
> my raid array. However during the rebuilding sda was detected as
> faulty. Now I am not sure what to do...
Unfortunately, you are suffering from classic timeout mismatch. I've
put some links in the postscript for you to read. Most likely, your
original sdc wasn't really bad.
[trim /]
> $ mdadm --examine /dev/sd[abcdefghijklmn]3 >> raid.status
> http://pastebin.com/qaP8bvna
Something's missing. I see only sd[abcd]3. Where's the report for
/dev/sde* ?
[trim /]
> Full dmesg available at:
> http://pastebin.com/bBfcYjkg
Yes, you have WD20EARS and ST3000DM001 drive models. These are not safe
to use in raid arrays due to lack of error recovery control.
> Is there some way to re-add this disk (sda) in the array without mdadm
> thinging it is a new one ?
You need to stop the array and perform an '--assemble --force' with the
last four devices (exclude /dev/sdc). The ones that have "Raid Device"
0, 1, 2, & 3.
If that fails, show mdadm's responses in your next reply. If it works,
your array will be available to mount, but degraded. You will not be
able to add your new sdc to the array while there are unresolved UREs,
so you will need to backup your important data from the degraded array.
UREs can only be fixed by writing over them -- normally done
automatically by MD with proper drives. You will have to overwrite
those spots with zeroes or use dd_rescue to move the data to fresh
drives (with zeroes in place of the unreadable spots).
> I have seen from the wiki that I could try to recreate the array with
> --assume-clean but I want to do that only in last resort.
Do *NOT* recreate the array. (Unless you're starting over after backing
up the files from the degraded array.)
Phil
[1] http://marc.info/?l=linux-raid&m=139050322510249&w=2
[2] http://marc.info/?l=linux-raid&m=135863964624202&w=2
[3] http://marc.info/?l=linux-raid&m=135811522817345&w=1
[4] http://marc.info/?l=linux-raid&m=133761065622164&w=2
[5] http://marc.info/?l=linux-raid&m=132477199207506
[6] http://marc.info/?l=linux-raid&m=133665797115876&w=2
[7] http://marc.info/?l=linux-raid&m=142487508806844&w=3
[8] http://marc.info/?l=linux-raid&m=144535576302583&w=2
^ permalink raw reply
* Re: How to recover after md crash during reshape?
From: Phil Turmel @ 2015-10-25 23:02 UTC (permalink / raw)
To: andras; +Cc: Linux-RAID
In-Reply-To: <72dc24dd30c19517d19887d794fd341b@tantosonline.com>
On 10/25/2015 10:15 AM, andras@tantosonline.com wrote:
> Phil,
>
> Thanks for all the help. I finally have some progress (and new problems).
> [ 5859.527778] EXT4-fs (md1): bad geometry: block count 1831419920
> exceeds size of device (1831419760 blocks)
> So, I thought of three ways of fixing it:
> 1. Re-create the array again, but this time force the array size to the
> one reported by the filesystem, using -size. What is the unit for -size?
> Is that bytes?
Yep. You'll need to use the --size option on a create. Note that it
specifies the amount of each device to use, not the overall array size.
According to "man mdadm", its units is k == 1024 bytes. Use the exact
size from your original => --size=1465135936
> 2. Re-create the array again, but this time use the original
> super-blocks version (0.91 I think). Could that make a difference in the
> size of the array?
v0.91 really is just a flag that means v0.90 w/ a reshape in progress.
But yes, the size used would be somewhat different. With the override
above, it won't matter. v1.x metadata has more features, and modern
mdadm normally reserves enough room to support them.
> 3. Instead of DD-ing whole drives, dd just the raid6 partitions so the
> partition table is correct for the drives. Maybe the misalignment trips
> mdadm off and makes it to create the array in the incorrect size?
Yes, dd just the partition contents, so the final array is aligned.
This is *really* important for drives that have logical 512-byte sectors
but physical 4k-sectors. When you put your repaired array back in
service, keep this alignment.
Phil
^ permalink raw reply
* Re: Fwd: manually destriping a 4 drive raid5 with one missing drive
From: Phil Turmel @ 2015-10-25 22:47 UTC (permalink / raw)
To: Marek; +Cc: Linux-RAID
In-Reply-To: <CA+sqOsYVGyCVKoRYAvgsL57tHhZn6+RaLK_7bzrUHvVK2XUNPA@mail.gmail.com>
Hi Marek,
On 10/23/2015 04:46 PM, Marek wrote:
> On Fri, Oct 23, 2015 at 7:49 PM, Phil Turmel <philip@turmel.org> wrote:
>> On 10/23/2015 12:20 PM, Marek wrote:
>>> Not sure if it's destrip or destripe but it's basically like puzzle
>>> you take a block from each drive according to the layout you are using
>>> e.g. Left symmetric and then write it down in that order computing
>>> missing blocks from parity blocks - this way you would write an image
>>> which you can mount without using mdadm. Data restoration companies
>>> are using this technique.
>>
>> No special tool required. Obtain a new drive big enough to hold your
>> entire array and 'dd' from /dev/mdX to your new drive.
> dd from mdX doesn't work i tried it even with testdisk, what you get
> is mixed up data, incomplete files.
Well, that suggests you've done more than just a forced resync. Pretty
much the only way to get this is to screw up the device order with
"mdadm --create --assume-clean"
You'll need to provide a great deal of data about your array and
precisely what you've done to it.
> { Google mail on iPad doesn't support plain text, who knew :/ }
{Top-posting fixed. Gmail screws this up by default, too.}
Phil
^ permalink raw reply
* Re: performance issue (was: Re: kernel: BUG: soft lockup - CPU#1 stuck for 60s!)
From: Neil Brown @ 2015-10-25 21:10 UTC (permalink / raw)
To: Rainer Fügenstein; +Cc: Linux-RAID
In-Reply-To: <1939397312.20151025213258@oudeis.org>
[-- Attachment #1: Type: text/plain, Size: 2379 bytes --]
Rainer Fügenstein <rfu@oudeis.org> writes:
> Hello Neil,
>
> Sunday, October 25, 2015, 9:08:39 PM, you wrote:
>
>> Depending on kernel version, it will either work or it won't.
> # mdadm --grow /dev/md0 --bitmap=none
> mdadm: failed to remove internal bitmap.
> md: couldn't update array info. -16
>
> so it doesn't work with this kernel. will upgrade ASAP.
>
>> Either way, it won't cause harm.
> famous last words ;-)
>
>> Weekly is a bit more often than I would go for, but why disable it?
> because a resync runs for a bit more than two days. but running it
> monthly seems to be a good trade-off.
>
>> That isn't a cronjob started resync. That would say "check" rather than
>> 'resync".
>> This looks a lot like a resync after an unclean restart. But with the
>> bitmap that should go faster...
> you've got me here. resync started at 04:22am, the same time as
> cron.weekly. there was a 99-raid-something script in cron.weekly
> (before I deleted it). system is up for some 2 days before the
> resync, so no unclean restart.
Hmmm... is your kernel older than 2.6.19? If so, that would explain it.
Prior to 2.6.19, 'check' was reported as 'resync'.
>
>> What does "mdadm --examine-bitmap /dev/sdb1" report?
>
> # mdadm --examine-bitmap /dev/sdb1
> Filename : /dev/sdb1
> Magic : 6d746962
> Version : 4
> UUID : 8d3586a2:6adbc781:ee187e6d:500f9b34
> Events : 4945261
> Events Cleared : 4945261
> State : OK
> Chunksize : 4 MB
> Daemon : 5s flush period
> Write Mode : Normal
> Sync Size : 2930265344 (2794.52 GiB 3000.59 GB)
> Bitmap : 715397 bits (chunks), 51 dirty (0.0%)
50% dirty! That is more than I would expect. So even if it was a real
resync it would be going quite slowly. I guess you'll just have to wait
it out.
Maybe you could:
echo idle > /sys/block/md0/md/sync_action
That will abort a 'check'. If it restarts automatically, md thinks it
was doing a real resync. If it doesn't you should be able to remove and
re-add the bitmap.
Then maybe check with --examine-bitmap again.
But definitely update your kernel if you are on 2.6.something.
NeilBrown
>
> hth.
>
> --
> Best regards,
> Rainer mailto:rfu@oudeis.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: performance issue (was: Re: kernel: BUG: soft lockup - CPU#1 stuck for 60s!)
From: Rainer Fügenstein @ 2015-10-25 20:32 UTC (permalink / raw)
To: Neil Brown; +Cc: Linux-RAID
In-Reply-To: <87a8r6g188.fsf@notabene.neil.brown.name>
Hello Neil,
Sunday, October 25, 2015, 9:08:39 PM, you wrote:
> Depending on kernel version, it will either work or it won't.
# mdadm --grow /dev/md0 --bitmap=none
mdadm: failed to remove internal bitmap.
md: couldn't update array info. -16
so it doesn't work with this kernel. will upgrade ASAP.
> Either way, it won't cause harm.
famous last words ;-)
> Weekly is a bit more often than I would go for, but why disable it?
because a resync runs for a bit more than two days. but running it
monthly seems to be a good trade-off.
> That isn't a cronjob started resync. That would say "check" rather than
> 'resync".
> This looks a lot like a resync after an unclean restart. But with the
> bitmap that should go faster...
you've got me here. resync started at 04:22am, the same time as
cron.weekly. there was a 99-raid-something script in cron.weekly
(before I deleted it). system is up for some 2 days before the
resync, so no unclean restart.
> What does "mdadm --examine-bitmap /dev/sdb1" report?
# mdadm --examine-bitmap /dev/sdb1
Filename : /dev/sdb1
Magic : 6d746962
Version : 4
UUID : 8d3586a2:6adbc781:ee187e6d:500f9b34
Events : 4945261
Events Cleared : 4945261
State : OK
Chunksize : 4 MB
Daemon : 5s flush period
Write Mode : Normal
Sync Size : 2930265344 (2794.52 GiB 3000.59 GB)
Bitmap : 715397 bits (chunks), 51 dirty (0.0%)
hth.
--
Best regards,
Rainer mailto:rfu@oudeis.org
^ permalink raw reply
* Re: Fwd: [PATCH] mdadm: Check bitmap first when reshape raid1 to raid0
From: Neil Brown @ 2015-10-25 20:21 UTC (permalink / raw)
To: Xiao Ni; +Cc: Jes Sorensen, linux-raid
In-Reply-To: <284284227.42321345.1445751531086.JavaMail.zimbra@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2331 bytes --]
Xiao Ni <xni@redhat.com> writes:
> Hi Neil
>
> I encountered one problem. When reshape one raid1 with bitmap to raid0, it'll
> lose legs.
>
> I sent the patch by git-send-email, but I can't see the mail in linux-raid. So
> I forward it again. And add signed-off-by line.
>
> Best Regards
> Xiao
>
> ----- Forwarded Message -----
> From: "Xiao Ni" <xni@redhat.com>
> To: xni@redhat.com
> Sent: Sunday, October 25, 2015 1:36:02 PM
> Subject: [PATCH] mdadm: Check bitmap first when reshape raid1 to raid0
>
> One raid1 with bitmap is composed by 4 disks. It'll fail when rashape to raid0
> and lose 3 disks. It should check bitmap first when reshape raid1 to raid0.
>
> Signed-off-by: Xiao Ni <xni@redhat.com>
> ---
> Grow.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/Grow.c b/Grow.c
> index 80d7b22..5e9b0bb 100644
> --- a/Grow.c
> +++ b/Grow.c
> @@ -1898,6 +1898,12 @@ size_change_error:
> array.layout == ((1 << 8) + 2) && !(array.raid_disks & 1)) ||
> (s->level == 0 && array.level == 1 && sra)) {
> int err;
> +
> + if (array.state & (1<<MD_SB_BITMAP_PRESENT)) {
> + cont_err("Bitmap must be removed before level can be changed\n");
> + rv = 1;
> + goto release;
> + }
> err = remove_disks_for_takeover(st, sra, array.layout);
> if (err) {
> dprintf("Array cannot be reshaped\n");
> @@ -2706,9 +2712,6 @@ static int impose_level(int fd, int level, char *devname, int verbose)
> err = errno;
> pr_err("%s: could not set level to %s\n",
> devname, c);
> - if (err == EBUSY &&
> - (array.state & (1<<MD_SB_BITMAP_PRESENT)))
> - cont_err("Bitmap must be removed before level can be changed\n");
> return err;
> }
> if (verbose >= 0)
> --
You appear to have identified a problem that needs fixing, but the
patch is fairly obviously wrong.
You've removed a test and error message that could apply to any level
change, and added a test and error message that only applies to some
specific level changes.
Why does that error message no longer apply to all the other possible
level changes?
The test that you have added is mostly OK ... but you missed something.
Look around and similar nearby code.
The test you removed certainly should stay.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: performance issue (was: Re: kernel: BUG: soft lockup - CPU#1 stuck for 60s!)
From: Neil Brown @ 2015-10-25 20:08 UTC (permalink / raw)
To: Rainer Fügenstein, Roman Mamedov; +Cc: Linux-RAID
In-Reply-To: <16514313.20151025202337@oudeis.org>
[-- Attachment #1: Type: text/plain, Size: 1839 bytes --]
Rainer Fügenstein <rfu@oudeis.org> writes:
> Hello Roman,
>
> Saturday, October 24, 2015, 6:31:39 PM, you wrote:
>
>> Use a higher bitmap-chunk size, such as 256M or more.
>
> I guess that would be
>
> mdadm --grow /dev/md0 --bitmap-chunk=256M ??
You would need to remove and then re-add the bitmap. So:
mdadm --grow /dev/md0 --bitmap=none
mdadm --grow /dev/md0 --bitmap=intermnal --bitmap-chunk=256M
>
> is it wise to issue this command during a re-sync?
Depending on kernel version, it will either work or it won't.
Either way, it won't cause harm.
>
> a cron.weekly job started the re-sync (although I'm pretty sure this
> job has been disabled quite some time ago)
Weekly is a bit more often than I would go for, but why disable it?
Regular scanning for latent bad blocks is fairly important for
reliability.
> $ cat /proc/mdstat
> Personalities : [raid6] [raid5] [raid4]
> md0 : active raid5 sdb1[7] sdf1[3] sdc1[5] sde1[0] sdd1[8]
> 11721061376 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/5] [UUUUU]
> [==>..................] resync = 11.9% (348948608/2930265344) finish=7771.1min speed=5533K/sec
> bitmap: 8/350 pages [32KB], 4096KB chunk
That isn't a cronjob started resync. That would say "check" rather than
'resync".
This looks a lot like a resync after an unclean restart. But with the
bitmap that should go faster...
What does "mdadm --examine-bitmap /dev/sdb1" report?
NeilBrown
>
> unused devices: <none>
>
> tnx & cu
>
> --
> Best regards,
> Rainer mailto:rfu@oudeis.org
>
> --
> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: performance issue (was: Re: kernel: BUG: soft lockup - CPU#1 stuck for 60s!)
From: Rainer Fügenstein @ 2015-10-25 19:23 UTC (permalink / raw)
To: Roman Mamedov; +Cc: Neil Brown, Linux-RAID
In-Reply-To: <20151024213139.5b20dec6@natsu>
Hello Roman,
Saturday, October 24, 2015, 6:31:39 PM, you wrote:
> Use a higher bitmap-chunk size, such as 256M or more.
I guess that would be
mdadm --grow /dev/md0 --bitmap-chunk=256M ??
is it wise to issue this command during a re-sync?
a cron.weekly job started the re-sync (although I'm pretty sure this
job has been disabled quite some time ago)
$ cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sdb1[7] sdf1[3] sdc1[5] sde1[0] sdd1[8]
11721061376 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/5] [UUUUU]
[==>..................] resync = 11.9% (348948608/2930265344) finish=7771.1min speed=5533K/sec
bitmap: 8/350 pages [32KB], 4096KB chunk
unused devices: <none>
tnx & cu
--
Best regards,
Rainer mailto:rfu@oudeis.org
^ 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