gmane.linux.raid

Скорое осиливанье

татуня — 2013-05-20T05:36:29

  Вы сможете говорить по великобритански исключительно после первого занятия. Обратить свою действительность многообразнее, подзаняться наипрекраснейшим делом. Экспресс обучение. Экспресс-курс для делающих первые щаги и углублённых. Интернет магазин: http://goo.gl/TXlwy .

Re: Resync raid array problem

Brad Campbell — 2013-05-20T03:46:17

Can't agree with this strongly enough. Grab the best UPS you can afford 
(and often that means getting a 10 year old one second hand and 
replacing the batteries). Best investment I _ever_ made was a 2000 
vintage APC SmartUPS 2200 and it cost all of about $200 second hand, 
plus another $100 for new batteries.

Also, look at adding a bitmap to your array. Then it will only resync 
what it suspects might be dirty.


--
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: Resync raid array problem

Sam Bingner — 2013-05-20T03:43:54


If you enable a bitmap on the device it should significantly lower the resync times.... but of curse this should not be a normal occurrence, or you have bigger problems...

Sam

--
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: Resync raid array problem

Keith Keller — 2013-05-20T02:53:59

You should probably have some sort of redundant power for such an
array--either a UPS or backup power provided by a building generator.


IIRC, a RAID5 is created by making the array in degraded mode and
resyncing the array.  So "create" and "resync" are basically equal in
duration in this scenario.  (I think creating a RAID6 works differently,
but it's possible that create and resync times are comparable as well.)

--keith

Resync raid array problem

Tarak — 2013-05-20T01:57:29

Hi 
We sucessfully created a Raid array of 8 harddisks.
On power failure situation, the resync of raid array 
is taking too much of time almost equal to 
the time taken for creating the raid array of hard disks.
Anyone is having an idea about this..
Please help me on this.

Regards
Tarak


--
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: [PATCH] md: Partially revert 2f6db2a7, which broke raid5

Kent Overstreet — 2013-05-19T17:51:45

Sorry for the delay - been vacationing. Reproduced the original bug,
here's a patch that fixes it:


commit 402f5db3708b2062795a384a3d8397cf702e27bc
Author: Kent Overstreet <koverstreet< at >google.com>
Date:   Sun May 19 10:27:07 2013 -0700

    raid5: Initialize bi_vcnt
    
    The patch that converted raid5 to use bio_reset() forgot to initialize
    bi_vcnt.
    
    Signed-off-by: Kent Overstreet <koverstreet< at >google.com>
    Cc: NeilBrown <neilb< at >suse.de>
    Cc: Jens Axboe <axboe< at >kernel.dk>
    Cc: linux-raid< at >vger.kernel.org

diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 9359828..753f318 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
< at >< at > -664,6 +664,7 < at >< at > static void ops_run_io(struct stripe_head *sh, struct stripe_head_state *s)
 if (test_bit(R5_ReadNoMerge, &sh->dev[i].flags))
 bi->bi_rw |= REQ_FLUSH;
 
+bi->bi_vcnt = 1;
 bi->bi_io_vec[0].bv_len = STRIPE_SIZE;
 bi->bi_io_vec[0].bv_offset = 0;
 bi->bi_size = STRIPE_SIZE;
< at >< at > -701,6 +702,7 < at >< at > static void ops_run_io(st

Genuine Cruzer Blade USB flash drive 8GB Flash Disk

Multicom Systems — 2013-05-17T14:02:12

Get a Genuine Cruzer Blade USB flash drive 8GB Flash Disk For Ksh 2000/= only

Click Here to View
http://www.sandisk.com/products/usb/drives/cruzer-blade/

With its stylish, compact design and generous capacity, the Cruzer Blade USB Flash Drive makes it easy to back up, transfer, and share your files. Available in capacities up to 32GB** , this USB drive lets you carry your photos, movies, music, and personal data wherever you go.

Compact design that fits in your pocket.

Drives up to 32GB can hold your most important data
SanDisk Secure Access software password protects** your files
Includes up to 2GB of online backup** with Yuu Waa
Transports important personal files, music, and video
 
Offer Valid while stock Last. Free Delivery within Nairobi. Make your order now.

"WARRANTY 1 YEAR"
 
Regards,
Jimmy
Multicom Systems (K)
Sales Team
multicomsystemskenya< at >gmail.com
Cell: 0721-946602
Nairobi - Kenya 

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to m

Re: [PATCH] md: Partially revert 2f6db2a7, which broke raid5

Jens Axboe — 2013-05-18T07:05:15

Kent, there was a report on this issue yesterday as well. We need to get
this fixed up ASAP.

[PATCH] raid5: After bio_reset, it must set some parameter of struct bio.

majianpeng — 2013-05-17T07:29:36

In commit 2f6db2a7073452b1, raid5 used bio_reset.But Kent Overstreet 
leak some fields of bio to set.So it will cause bugs:
[  355.746233] md/raid:md0: raid level 5 active with 3 out of 4 devices, algorithm 2
[  355.783651] ------------[ cut here ]------------
[  355.783707] kernel BUG at drivers/scsi/scsi_lib.c:1196!
[  355.783756] invalid opcode: 0000 [#1] SMP 
[  355.783846] Modules linked in: raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx netconsole configfs e1000e btrfs xor raid6_pq
[  355.784208] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-rc1+ #158
[  355.784261] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080015  11/09/2011
[  355.784336] task: ffffffff81c10440 ti: ffffffff81c00000 task.ti: ffffffff81c00000
[  355.784386] RIP: 0010:[<ffffffff81428fd2>]  [<ffffffff81428fd2>] scsi_setup_fs_cmnd+0x92/0xa0
[  355.784469] RSP: 0018:ffff8800bd203c48  EFLAGS: 00010046
[  355.784517] RAX: 0000000000000000 RBX: ffff880036e1a000

RAID 5 - All superblocks gone due to MBR/GPT mishap - how do i figure out chunk size?

den RDC — 2013-05-16T19:24:12

Hello

Due to a nasty (human) error,  4 2tb disks in raid5 have lost their
1st megabyte of data ( including superblock ). In an attempt to get
the array to a state usable enough to at least attempt data recovery,
I have been trying to re-enable the array using various chunk size and
partition start offsets, but i cant seem to get it anywhere near a
consistent state ( recovery tools only return files or pieces of files
smaller then the chunk size, indicating alignment/chunk size
inconsistencies ).

The data I do have is :
- the order of the disks
- the pretty solid assumption that all data, even parity should be
fine for most of the disk except the very beginning.
- the exact size of the MD device before it got corrupted.

Is there any way, however adventurous, to glean the missing data (
chunk size, chunk alignment/offset ) from analysis of the existing
data ?

Kind regards
den_RDC
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo< at >vger.kernel.org
M

Re: BUG - raid 1 deadlock on handle_read_error / wait_barrier

Alexander Lyakas — 2013-05-16T14:07:04

Hello Neil,
we are hitting issue that looks very similar; we are on kernel 3.8.2.
The array is a 2-device raid1, which experienced a drive failure, but
then drive was removed and re-added back to the array (although
rebuild never started). Relevant parts of the kernel log:

May 16 11:12:14  kernel: [46850.090499] md/raid1:md2: Disk failure on
dm-6, disabling device.
May 16 11:12:14  kernel: [46850.090499] md/raid1:md2: Operation
continuing on 1 devices.
May 16 11:12:14  kernel: [46850.090511] md: super_written gets
error=-5, uptodate=0
May 16 11:12:14  kernel: [46850.090676] md/raid1:md2: dm-6:
rescheduling sector 18040736
May 16 11:12:14  kernel: [46850.090764] md/raid1:md2: dm-6:
rescheduling sector 20367040
May 16 11:12:14  kernel: [46850.090826] md/raid1:md2: dm-6:
rescheduling sector 17613504
May 16 11:12:14  kernel: [46850.090883] md/raid1:md2: dm-6:
rescheduling sector 18042720
May 16 11:12:15  kernel: [46850.229970] md/raid1:md2: redirecting
sector 18040736 to other mirror: dm-13
May 16 11:12:15  ker

RE: Kernel crash at md_seq_show of drivers/md/md.c

Mo, Moore — 2013-05-16T12:35:25

Thanks your information and sorry about that I haven't look through latest mainline kernel this time. I will pay attention to it in future.

I have merged the patch from linux 3.1 (with a little adaptation for 2.6.37), and verified on my issue theater. it works well. The Oops disappeared. Thank you.

Could you mind I ask an extended question: There is a NULL pointer protector in md_wakeup_thread. Why not set the thread pointer to NULL instant after md_unregister_thread in fail case of run? Just like as fail case of raid5 implement in 01f96c0a9922cd9919baf9d16febdf7016177a12~1. 

-------------------------------------------------
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 43709fa..ac5e8b5 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
< at >< at > -4941,8 +4941,7 < at >< at > static int run(mddev_t *mddev)

        return 0;
 abort:
-       md_unregister_thread(mddev->thread);
-       mddev->thread = NULL;
+       md_unregister_thread(&mddev->thread);
        if (conf) {

Re: SpareMissing event, but spare not missing

Ole Tange — 2013-05-16T08:02:04

Nope.


Good call. It was generated automatically when there were 4 spares, so
it had 'spares=4' in it. And there are no longer 4 spares, which can
explain the message.

I have now removed the 'spares=4' and restarted mdadm --monitor.
Tomorrow we will see if that fixed it.


We are migrating to a RAID60 2x10.

The major reason for this is the time to rebuild: To rebuild one of
the 19 drives we have to read remaining 19 drives during which the
performance will be slower. On our system rebuild would take at least
4 days.


/Ole
--
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: [PATCH 9/9] mdadm: 'dump' support

NeilBrown — 2013-05-16T05:11:59

On Tue, 30 Aug 2011 12:12:03 +0200 Alexander Kühn
<alexander.kuehn< at >nagilum.de> wrote:


Nearly two years later, I've committed some functionality based on this.

mdadm --dump=/root/md /dev/*

will create files in /root/md/ with metadata from any device with metadata
recognised by mdadm.

mdadm --restore=/root/md /dev/*

will restore it all.

More details in the man page.
http://git.neil.brown.name/git?p=mdadm.git;a=blob;f=mdadm.8.in;h=c8559dae8e789a30e0c4ee826745a42980629977;hb=74db60b00a43a5ae636477c10c24e923e76049ce

NeilBrown

Re: 0.90 vs 1.X - Differing behavior for device # during fail/remove/add operation

Dusty Mabe — 2013-05-16T04:14:19


Excellent points. Yes it would be a sort of an API change which would
not be good for people who depend on it to act that way. That is sort
of how I ended up "caring so much" about it in the first place. 0.90
metadata behaved one way and now 1.X behaves differently so I need to
update some tools to take that into account. Before I updated the
tools I wanted to make sure it wasn't a "bug" and something that you
wanted to fix. If it was then I would possibly try to pull in the
kernel patch rather than change the tools.


This looks nice but I wouldn't discount the value of /proc/mdstat. If
monitoring tools check the status of raid often then I would rather
them use file I/O of a file maintained by the kernel rather than
running a command each time and parsing output.

Thanks for collaborating with me on this. I'll update my tools.

Dusty Mabe
--
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.kerne

Re: Kernel crash at md_seq_show of drivers/md/md.c

NeilBrown — 2013-05-16T01:19:05


I don't really have time for bug reports against ancient kernels - sorry.
If you think you've found a bug, please at least look in the current mainline
kernel to see if the code has changed, and preferably reproduce against the
current mainline kernel.

In this case the bug was fixed by commit
      01f96c0a9922cd9919baf9d16febdf7016177a12
18 months ago (linux 3.1).

NeilBrown

Re: 0.90 vs 1.X - Differing behavior for device # during fail/remove/add operation

NeilBrown — 2013-05-16T00:41:39


The problem with doing this is that it is potentially an API change.
It is unlikely but possible that some script depends on the current meaning
of the number.

Also it would result in spares being reported as e.g.
     sda1[-1]S
as 'raid_disk' for a spare is '-1'.


My leaning is to not worry too much about /proc/mdstat, but instead add a
"--status" option to "mdadm" which prints out a summary similar
to /proc/mdstat, but more coherent and less full of noise.

mdadm --status

md0 : raid1 chunk=65536K bitmap_chunk=8KB metadata=1.2 size=976762496K
   Working: 3[U_U] sda[0] sdc[1]
   Spares: sdd
   Failed: sdb

or something like that.

NeilBrown

Re: SpareMissing event, but spare not missing

Roy Sigurd Karlsbakk — 2013-05-15T15:24:29

- Anything in dmesg?
- What does /etc/mdadm/mdadm.conf say?

Also, using 20 disks in a single RAID-6 gives you the same chances for a parity+1 error (or worse) as compared to 10 drives in RAID-5. I would really recommend using smaller (8+2?) RAID-6 sets and rather use LVM on top (which you may be doing already?). Even with proper cooling and enterprise drives, 20 drives in a single RAID-6 is asking for trouble…

roy

----- Opprinnelig melding -----

SpareMissing event, but spare not missing

Ole Tange — 2013-05-15T13:51:37

The last couple of days I have received a warning about a missing
spare for a device that has several spares.

  A SparesMissing event had been detected on md device /dev/md1.
  :
  md1 : active raid6 sdas[12](S) sdx[0] sdaq[11](S) sdau[13](S)
sdah[9] sdaf[8] sdae[7] sdad[6] sdac[5] sdab[4] sdaa[3] sdz[2] sdy[1]
      31256138752 blocks super 1.2 level 6, 128k chunk, algorithm 2
[10/10] [UUUUUUUUUU]
      bitmap: 0/2 pages [0KB], 1048576KB chunk

I have tried removing one of the spares and adding it again. Same error.

$ mdadm --version
mdadm - v3.1.4 - 31st August 2010
$ uname -a
Linux orsted 3.2.0-0.bpo.1-amd64 #1 SMP Sat Feb 11 08:41:32 UTC 2012
x86_64 GNU/Linux

/Ole


The automated mail:

This is an automatically generated mail message from mdadm
running on orsted

A SparesMissing event had been detected on md device /dev/md1.

Faithfully yours, etc.

P.S. The /proc/mdstat file currently contains the following:

Personalities : [raid6] [raid5] [raid4] [raid0]
md3 : active raid0 md1[0] md2[1]
      62512

Re: Kernel crash at md_seq_show of drivers/md/md.c

Mo, Moore — 2013-05-15T12:11:52

Dear Neil,

Thank you for your clue. I make deeper trace after that and found another suspicion point. Kernel maybe wakeup a mdk_thread which was kfree in failed case of mddev->pers->run(mddev).

For make sure my guess, I add some printk in order to get more info. It seems that md_seq_show try to wake up a mdk_thread in mddev_unlock() before md_seq_show return, but the thread was kfree already by "out_free_conf" case of run() function in drivers/md/raid10.c.

The Oops report as attached.

----------------- Patch of my debug code ---------------------------
Index: drivers/md/md.c
===================================================================
--- drivers/md/md.c     (revision 1911)
+++ drivers/md/md.c     (working copy)
< at >< at > -675,6 +675,8 < at >< at >
        } else
                mutex_unlock(&mddev->reconfig_mutex);
 
+       if(mddev->thread)
+               printk("%s:%d Try to md_wakeup_thread(%p) of dev(%p)\n", __func__, __LINE__, mddev->thread, mddev);
        md_wakeup_thread(mddev->thr

Fwd: Corruption during RAID5->RAID6 migration

James Doebbler — 2013-05-14T22:07:22

Roman,

Thank you very much, I hadn't seen those reports.  I had searched
through the Newegg reviews for linux/ubuntu and saw good
support/reviews.  Now searching more generally I see several
corruption reports in the feedback.  Wow, that's really bad.  I'll
definitely be leaving some reviews there of my own to warn others.

I have on hand a HighPoint Rocket 640L 4-port SATAIII card (Marvell
88SE9235 chipset) which I can use.  I will do some research, but do
you know of any issues with this card/chipset?  If so, can you
recommend a reliable, inexpensive card or cards?  I have one each
PCI-Express 1x and 16x slots available and would like a total of 6 or
more SATAII or SATAIII ports.


It is interesting that I was still seeing problems after only having
one drive active across the two cards.  I'll be avoiding using even
one port at a time on these cards.

Based on my high-level understanding, the reshape shouldn't read any
data from the two new drives during the reshape, just write to them.
All read data shou