gmane.linux.raid

Re: RAID6 growing interrupted, array won't assemble or resume growing

Nic Wolfe — 2013-06-19T23:52:22


OK, will do. Simply "mdadm --assemble /dev/md1 /dev/sdb /dev/sdd
/dev/sde /dev/sdf /dev/sdg"?

Thanks so much for all the help so far.

Nic
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Growing a 5-drive RAID6 - some initial questions

Mark Knecht — 2013-06-19T21:39:58

Hi,
   On my home server my / partition is a 5-drive RAID6 which doesn't
extend to the full extent of the drive. I've now removed everything to
the end of the drive (saved to external USB drives for now) and am
interested in growing the RAID6 to use all the disk space available.
Before I start I've got a couple of questions. Note that I have no
storage space issues. I only use about 200GB total on this machine so
the new, larger RAID6 will be more than large enough. I do value
having RAID6 and being able to lose two drives.

1) Is the fail/remove/partition/add method shown here a reasonable
method for my task?

https://raid.wiki.kernel.org/index.php/Growing

2) The RAID is a 5-drive RAID6 using a 16K chunk size. Would
performance be helped significantly using some other chunk size?

   I am not overly concerned about how long it takes to complete. It
seems to me that failing 1 drive in a RAID6 built using 500GB RE3 WD
drives is _reasonably_ safe. The drives came from 3 different orders
at Amazon spanning abo

Re: RAID6 growing interrupted, array won't assemble or resume growing

Phil Turmel — 2013-06-19T18:36:52


You trimmed here...  Per the linked reports, you have this problem.


Drive /dev/sdc has pending relocations.  Those are bad sectors that need
to be rewritten to either fix them or relocate them.  You are unable to
do that with your raid card because /dev/sdc does not support error
recovery control.

In fact, only your /dev/sdd supports it, and as a desktop drive, it
defaults to "Off" on every power cycle.

[trim /]


Some raid cards use part of the drive space to write management data,
and show a smaller drive to the OS.  If this is your case, you can
manually set up device mapper to expose the smaller areas as devices,
and build the MD array from those.  Detailed information about your
device sizes with and without the raid card would be needed.


No.  /dev/sdc is your problem.  There might be more, but they aren't
exposed in SMART yet.


As noted above, you will not be able to use /dev/sdc with the raid card.
 You could try leaving it out and taking a backup with the degraded
array.  That is what I woul

Re: [PATCH 2/6] Makefile: Allow the user to pass EXTRA_CFLAGS

Bernd Schubert — 2013-06-19T09:48:47

Hello Neil,

On 06/19/2013 02:07 AM, NeilBrown wrote:


I'm sorry for the extra work with the white space. Next time I'm first 
going to run linux/scripts/checkpatch.pl

Hmm, indeed

make CXFLAGS=-O3

works, but the other way around it does not:

CXFLAGS=-O3 make

I still wonder how it works, as Makefile sets "CXFLAGS = -ggdb".
Anyway, whichever exception 'make' has for that, can we change it to

-CXFLAGS = -ggdb
+CXFLAGS ?= -ggdb

which would make it work with either way CXFLAGS is specified.


Thanks,
Bernd

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RAID6 growing interrupted, array won't assemble or resume growing

Nic Wolfe — 2013-06-19T06:21:03

Done, thanks.


[trim /]


OK I have built a PC with properly supported hardware that I can now
hook all my drives up to directly. Unfortunately because they were
being managed by the RAID card before as single drive JBOD arrays they
do not show up as md devices on the new PC, so I will have to attempt
to get this array running on the old PC with the old RAID/JBOD setup.

On the new PC I can see the SMART info but since the drives will have
to be managed by the RAID card anyway I'm not sure if it is prudent to
mess with the settings. It does sound like a good idea to maybe
increase the timeouts on the OS though ("echo 180
were just power in the first place?

In case it helps though:

sdb: http://pastebin.com/btrpcMF0
sdc: http://pastebin.com/kdcrf9mY
sdd: http://pastebin.com/S0nj9Ma9
sde: http://pastebin.com/G3vUZf92
sdf: http://pastebin.com/0P2LbDQq
sdg: http://pastebin.com/8q4vuU1a

Finally, I don't actually necessarily need to finish the reshape; I
just want to get the data off. Can I assemble the array

Re: Optimal value for bitmap-chunk option

Roman Mamedov — 2013-06-19T04:38:38

On Tue, 18 Jun 2013 16:52:09 +0400
Роман Алексеев  <r.alekseev< at >qwarta.ru> wrote:


It's just the minimum granularity of pieces that get rebuilt after unclean
shutdowns. E.g. if your array decides it's "dirty" in 5 different areas, with
a 16MB chunk the rebuild will process 5*16MB, but with a 128MB it will rebuild
5*128MB. On modern systems the difference in time required to do the rebuild
between these two will be negligible. But having a larger size helps
noticeably in everyday operation (makes writes faster). So there is nothing to
"calculate" really, just use a reasonably large size like 128 or 256 MB.

https://raid.wiki.kernel.org/index.php/Write-intent_bitmap
http://techblog.tgharold.com/2013/01/mdadm-using-bitmaps-to-speed-up-rebuilds.html
http://blog.liw.fi/posts/write-intent-bitmaps/ (the 1st comment)

Re: [PATCH 0/6] raid6check fixes

NeilBrown — 2013-06-19T00:08:03

On Tue, 18 Jun 2013 11:09:10 +0200 Bernd Schubert
<bernd.schubert< at >itwm.fraunhofer.de> wrote:


Thanks for mentioning that.  I've fix that problem.

NeilBrown

Re: [PATCH 2/6] Makefile: Allow the user to pass EXTRA_CFLAGS

NeilBrown — 2013-06-19T00:07:30

On Tue, 18 Jun 2013 11:09:21 +0200 Bernd Schubert
<bernd.schubert< at >itwm.fraunhofer.de> wrote:


Doesn't it?  It works for me.

   make CXFLAGS=-O3

compiled with "-O3".


I haven't applied this patch (feel free to try to be more convincing) but has
applied all the others (after removing a little bit of trailing white space).

Thanks,
NeilBrown

Re: Proper way to delete an old RAID1?

Mark Knecht — 2013-06-18T20:02:30

I suppose one other small point on this topic, should anyone read it
in the distant future, is that once I've stopped the RAID and zero'ed
the superblocks the RAID itself is gone and cannot be reassembled but
the partitions are still there, and they are still marked as 'Linux
raid autodetect' in fdisk.

To move forward with growing other RAIDs I need to remove the existing
but now unused partitions to make room for future changes.

Cheers,
Mark
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Proper way to delete an old RAID1?

Mark Knecht — 2013-06-18T19:08:25

You're right, I'm wrong. It was #6 I was referring to when I first posted.

Thanks for the correction. We'll see if anyone else suggests #6 actually works.

Cheers,
Mark
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Proper way to delete an old RAID1?

Caspar Smit — 2013-06-18T19:01:56

Mark,

His instructions at #3 are correct, #6 are incorrect (or someone has
to correct me and knows the --remove will work on an entire MD
device?).


Kind regards,
Caspar
Met vriendelijke groet,

Caspar Smit
Systemengineer
TB BV
Dorsvlegelstraat 13
1445 PA Purmerend

T: +31(0)299 410 475
F: +31(0)299 410 476
< at >: c.smit< at >truebit.nl
W: www.truebit.nl


2013/6/18 Mark Knecht <markknecht< at >gmail.com>:
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Proper way to delete an old RAID1?

Mark Knecht — 2013-06-18T18:55:08

Thanks Caspar. What you are saying makes more sense to me and is, as
best I can tell, consistent with man mdadm.

I've used this site a few times as it seems to come up a lot when
Googling mdadm questions:

http://www.ducea.com/2009/03/08/mdadm-cheat-sheet/

Apparently his instructions in #3 are incorrect.

Cheers,
Mark

<SNIP>
<SNIP>
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Proper way to delete an old RAID1?

Caspar Smit — 2013-06-18T18:42:14

Hi Mark,

Stopping an MD device will not remove/delete anything.
The --remove command cannot be used AFTER an MD device is stopped.
(--remove is only for removing drives/partitions from a running MD
device NOT to remove the MD itself e.g. mdadm --remove /dev/mdX
/dev/sdb, furthermore a drive/partition can only be removed after you
fail the drive first or it has failed by itself offcouse, see the
--fail switch)

To completely erase the MD you need to stop it and then remove the
superblocks from the member drives:

mdadm --stop /dev/md127
mdadm --zero-superblock /dev/sdb5
mdadm --zero-superblock /dev/sdc5
mdadm --zero-superblock /dev/sdd5

You can combine the last 3 commands to:

mdadm --zero-superblock /dev/sd[b-d]5

but to be 100% safe use them seperately.

This will erase the superblocks on the members of /dev/md127 and you
will not be able to assemble it again and it will not be started
during a reboot (remove it from the mdadm.conf too offcourse, but
since the array comes up as /dev/md127 I presume it is

Proper way to delete an old RAID1?

Mark Knecht — 2013-06-18T17:36:08

I'm in the process of trying to clean up my home server. When I first
built the machine the main RAID was a partition-based 0.90 RAID1 which
is no longer used. I would like to get rid of this RAID (/dev/md127)
completely. What's the right way to do this?

mark< at >c2RAID6 ~ $ cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md6 : active raid5 sdd6[2] sdb6[0] sdc6[1]
      494833664 blocks super 1.1 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
      bitmap: 0/2 pages [0KB], 65536KB chunk

md7 : active raid6 sdd7[2] sdc7[1] sdb7[0] sdf2[4] sde2[3]
      395387904 blocks super 1.2 level 6, 16k chunk, algorithm 2 [5/5] [UUUUU]

md127 : active (auto-read-only) raid1 sdc5[1] sdd5[2] sdb5[0]
      52436032 blocks [3/3] [UUU]

md3 : active raid6 sdb3[0] sdf3[5] sde3[3] sdd3[2] sdc3[1]
      157305168 blocks super 1.2 level 6, 16k chunk, algorithm 2 [5/5] [UUUUU]

unused devices: <none>
mark< at >c2RAID6 ~ $

To I need to do anything more than:

mdadm --stop /dev/md127
mdadm --remove /

Re: [PATCH 0/6] raid6check fixes

Piergiorgio Sartor — 2013-06-18T17:16:33

Hi Bernd,

cool!!!

Good you're keeping it up!

bye,

Set AUTOCHECK=false

Роман Алексеев — 2013-06-18T13:15:04

Hi,

Could someone explain me what can happen if I disable AUTOCHECK option 
in /etc/default/mdadm file?

Thanks

Optimal value for bitmap-chunk option

Роман Алексеев — 2013-06-18T12:52:09

Hello,

I want to speed up rebuilding process of the raid to do that I'm going
to apply the command:

mdadm --grow --bitmap=internal --bitmap-chunk=NNNN /dev/mdX

But I don't know how to calculate optimal value of bitmap-chunk option.
How can I do that?

Any help would be greatly appreciated.

--
Roman
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/6] raid6check fixes

Bernd Schubert — 2013-06-18T09:09:10

Here are a few raid6check fixes. This series also includes a patch for
Makefile to allow to build with optimizations. I only fixed raid6check
to build with -O3, but I don't have time left today to fix mdadm 
(e.g. Grow.c:2237:41: error: ‘info2.data_offset’ may be used uninitialized in this function [-Werror=uninitialized])

I wanted to send the memleak-fixes much earlier, but then
I had been too busy. This patch is lightly tested, patches
from today are only build-tested.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/6] raid6check: Fix memory leaks detected by valgrind

Bernd Schubert — 2013-06-18T09:09:26

==2389947== 24 bytes in 1 blocks are definitely lost in loss record 1 of 10
==2389947==    at 0x4C2B3F8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2389947==    by 0x408067: xmalloc (xmalloc.c:36)
==2389947==    by 0x401B19: check_stripes (raid6check.c:151)
==2389947==    by 0x4030C6: main (raid6check.c:521)
==2389947==
==2389947== 24 bytes in 1 blocks are definitely lost in loss record 2 of 10
==2389947==    at 0x4C2B3F8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2389947==    by 0x408067: xmalloc (xmalloc.c:36)
==2389947==    by 0x401B67: check_stripes (raid6check.c:155)
==2389947==    by 0x4030C6: main (raid6check.c:521)
==2389947==

Signed-off-by: Bernd Schubert <bernd.schubert< at >fastmail.fm>
---
 raid6check.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/raid6check.c b/raid6check.c
index f5aeee4..17f7430 100644
--- a/raid6check.c
+++ b/raid6check.c
< at >< at > -325,9 +325,11 < at >< at > exitCheck:
 free(stripe_buf);
 free(stripes);
 free(blocks);
+free(block_inde

[PATCH 6/6] raid6check: Check return value of lseek64()

Bernd Schubert — 2013-06-18T09:09:41

If lseek64() failed it was still writing to the disks, which would introduce
data corruption.

Signed-off-by: Bernd Schubert <bernd.schubert< at >fastmail.fm>
---
 raid6check.c |   32 ++++++++++++++++++++++++++++----
 1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/raid6check.c b/raid6check.c
index 90a7fd3..ee0de2f 100644
--- a/raid6check.c
+++ b/raid6check.c
< at >< at > -185,11 +185,19 < at >< at > int check_stripes(struct mdinfo *info, int *source, unsigned long long *offsets,
 goto exitCheck;
 }
 for (i = 0 ; i < raid_disks ; i++) {
-lseek64(source[i], offsets[i] + start * chunk_size, 0);
+off64_t seek_res = lseek64(source[i], offsets[i] + start * chunk_size, 
+   SEEK_SET);
+if (seek_res < 0) {
+fprintf(stderr, "lseek to source %d failed\n", i);
+unlock_all_stripes(info, sig);
+err = -1;
+goto exitCheck;
+}
 int read_res = read(source[i], stripes[i], chunk_size);
 if (read_res < chunk_size) {
 fprintf(stderr, "Failed to read complete chunk disk %d, aborting\n", i

[PATCH 5/6] raid6check: Fix compiler warnings.

Bernd Schubert — 2013-06-18T09:09:36

Fix some compiler warnings appearing with optimization levels.

Signed-off-by: Bernd Schubert <bernd.schubert< at >fastmail.fm>
---
 raid6check.c |   32 ++++++++++++++++++++++++++------
 1 file changed, 26 insertions(+), 6 deletions(-)

diff --git a/raid6check.c b/raid6check.c
index 480422d..90a7fd3 100644
--- a/raid6check.c
+++ b/raid6check.c
< at >< at > -186,7 +186,12 < at >< at > int check_stripes(struct mdinfo *info, int *source, unsigned long long *offsets,
 }
 for (i = 0 ; i < raid_disks ; i++) {
 lseek64(source[i], offsets[i] + start * chunk_size, 0);
-read(source[i], stripes[i], chunk_size);
+int read_res = read(source[i], stripes[i], chunk_size);
+if (read_res < chunk_size) {
+fprintf(stderr, "Failed to read complete chunk disk %d, aborting\n", i);
+unlock_all_stripes(info, sig);
+goto exitCheck;
+}
 }
 err = unlock_all_stripes(info, sig);
 if(err != 0)
< at >< at > -282,14 +287,23 < at >< at > int check_stripes(struct mdinfo *info, int *source, unsigned long long *offsets,
 goto exitCheck;
 }
 
+