headers
Alexander Kühn | 30 Aug 2011 12:12
Picon

Re: [PATCH 9/9] mdadm: 'dump' support


Zitat von NeilBrown <neilb <at> suse.de>:

> On Thu, 25 Aug 2011 19:14:45 -0700 Dan Williams <dan.j.williams <at> intel.com>
> wrote:
>
>>   mdadm -E /dev/sda --dump=foo
>>
>> Creates a sparse file image of /dev/sda named foo with a copy of the
>> metadata instance found by -E.
>>
>> When used in the opposite direction:
>>
>>   mdadm -E foo --dump=/dev/sda
>>
>> ...can restore metadata to a given block device, assuming it is
>> identical size to the dump file.
>
> Suppose we did have a separate 'restore' function - what would it look like?
> An option to create?
>
>   mdadm --create --restore=some-directory /dev/sda /dev/sdb
>

Yes, from a UI perspective having separate dump/restore options is  
better. Since there is also dump(8)/restore(8) it would also keep the  
nomenclature.
Otherwise I would rather name it "copy-metadata" or something as with  
copying the user is or should be aware that the order or arguments  
matters.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stefan G. Weichinger | 30 Aug 2011 14:14
Picon

Re: (solved) RAID1, changed disk, 2nd has errors ...

Am 30.08.2011 01:40, schrieb Mathias Burén:

> Glad you got it working, but your drive looks like a failing drive
> to me, because of these:
> 
> 187 Reported_Uncorrect      0x0032   082   082   000    Old_age
> Always -       18
> 
> So I'd replace it ASAP.

As mentioned, I ordered the new disk already.

--
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
Permalink | Reply | 0 comments |
headers
Patelczyk, Maciej | 30 Aug 2011 15:30
Picon
Favicon

RE: [PATCH] mdadm: close parent file descriptors when starting mdmon.

> -----Original Message-----
> From: NeilBrown [mailto:neilb <at> suse.de]
> Sent: Tuesday, August 30, 2011 1:32 AM
> To: Patelczyk, Maciej
> Cc: linux-raid <at> vger.kernel.org
> Subject: Re: [PATCH] mdadm: close parent file descriptors when starting
> mdmon.
> 
> On Mon, 29 Aug 2011 17:49:49 +0200 Maciej Patelczyk
> <maciej.patelczyk <at> intel.com> wrote:
> 
> > When mdadm is invoked by fork-and-exec it inherits all open file
> > descriptors and when mdadm forks to exec mdmon those file descriptors
> > are passed to mdmon. Mdmon closes only first 97 fd and that in some
> > cases is not enough.
> 
> Can you describe and actual can when it is not enough?  Maybe there is
> some
> other problem where mdadm is not closing things as it should.

There is one:
CIM Server (Sfcbd - Small Footprint CIM Broker) -> registered provider 
-> intermediate library -> mdadm -> mdmon

We register provider in Sfcbd which brings some functionality to cim server.
It uses our library which calls mdadm (popen). Later mdadm is calling mdmon
(fork&exec).

The problem is that Sfcbd is a server and it has more than 100 files opened.
Open files handles are passed down to mdadm (popen behavior) and here we have
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alexander Lyakas | 30 Aug 2011 17:18
Picon

Re: MD devnode still present after 'remove' udev event, and mdadm reports 'does not appear to be active'

Thanks, Neil.

Although according to udev documentation: "the udev events are sent
out after udev has finished its event processing, all rules have been
processed, and needed device nodes are created."

Also looking at udev-worker code of udevd, the
udev_monitor_send_device() call is done after all the rules have been
processed.

Nevertheless, I looked at udevadm_settle.c and did some equivalent of
that in my code, and it looks like the issue is resolved. Perhaps
there is something md-specific here?

Another thing, since you are reading this thread, I wanted to ask
whether you have any advice on the "RAID5: failing an active component
during spare rebuild - arrays hangs" thread I opened some time ago.
Since you were not answering, I assume there is nothing additional you
can advise about, correct? I apologize if this off-topic was
inappropriate.

Thanks for the help,
  Alex.

On Tue, Aug 30, 2011 at 12:25 AM, NeilBrown <neilb <at> suse.de> wrote:
> On Mon, 29 Aug 2011 20:17:34 +0300 Alexander Lyakas <alex.bolshoy <at> gmail.com>
> wrote:
>
>> Greetings everybody,
>>
(Continue reading)

Permalink | Reply | 2 comments |
headers
NeilBrown | 31 Aug 2011 02:54
Picon
Gravatar

Re: MD devnode still present after 'remove' udev event, and mdadm reports 'does not appear to be active'

On Tue, 30 Aug 2011 18:18:11 +0300 Alexander Lyakas <alex.bolshoy <at> gmail.com>
wrote:

> Thanks, Neil.
> 
> Although according to udev documentation: "the udev events are sent
> out after udev has finished its event processing, all rules have been
> processed, and needed device nodes are created."
> 
> Also looking at udev-worker code of udevd, the
> udev_monitor_send_device() call is done after all the rules have been
> processed.
> 
> Nevertheless, I looked at udevadm_settle.c and did some equivalent of
> that in my code, and it looks like the issue is resolved. Perhaps
> there is something md-specific here?

I cannot see how it would be md-specific.  mdadm doesn't create or remove
devices when udev is active - it leaves all that to udev.
If you are curious I suggest you ask the udev developers.

> 
> Another thing, since you are reading this thread, I wanted to ask
> whether you have any advice on the "RAID5: failing an active component
> during spare rebuild - arrays hangs" thread I opened some time ago.
> Since you were not answering, I assume there is nothing additional you
> can advise about, correct? I apologize if this off-topic was
> inappropriate.

It could mean that I had nothing extra to say, but it could also mean that I
(Continue reading)

Permalink | Reply | 1 comment |
headers
NeilBrown | 31 Aug 2011 04:46
Picon
Gravatar

Re: RAID5: failing an active component during spare rebuild - arrays hangs

On Thu, 25 Aug 2011 11:59:27 +0300 Alexander Lyakas <alex.bolshoy <at> gmail.com>
wrote:

> Hello Neal,
> how can we further check this issue?
> Additional piece of information is that the  md1123_raid5 is at 100%
> CPU in top output. And I do this test on a virtual machine with KVM.
> 

The fact that md1123_raid5 is spinning suggest there is one request that
is being handled over and over again - each time handle_stripe5 thinks that
it cannot handle it yet, but leaves it in a state which indicates that it
still needs handling.
However I cannot see how that could possible happen.

If your kernel had dynamic debugging enabled we  could turn that on for RAID5
and  see a bit more of what is happening.
i.e.
  echo module raid456 > /sys/kernel/debug/dynamic_debug/control

with the debug filesystem mounted on /sys/kernel/debug

However that Ubuntu kernel doesn't have CONFIG_DYNAMIC_DEBUG set so you
would need to compile a new kernel.

I cannot think of any other way forward with this.

BTW when I tested your script on the very latest kernel I hit a completely
unrelated bug what was introduced very recently which I can now fix.  So I'm
particularly glad that I looked at this :-)
(Continue reading)

Permalink | Reply | 7 comments |
headers
NeilBrown | 31 Aug 2011 08:45
Picon
Gravatar

[PULL REQUEST] md fixes for 3.1


Hi Linus,
 please pull assorted small md fixes as follows.

Thanks,
NeilBrown

The following changes since commit 14c62e78dc1379185515be41903c4a667efc6d54:

  Merge branch 'x86-urgent-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip (2011-08-23 18:09:08 -0700)

are available in the git repository at:

  git://neil.brown.name/md for-linus

Namhyung Kim (1):
      md: use REQ_NOIDLE flag in md_super_write()

NeilBrown (5):
      md: report failure if a 'set faulty' request doesn't.
      md: ensure changes to 'write-mostly' are reflected in metadata.
      md/linear: avoid corrupting structure while waiting for rcu_free to complete.
      md: fix clearing of 'blocked' flag in the presence of bad blocks.
      md/raid5: fix a hang on device failure.

 drivers/md/linear.h |    2 +-
 drivers/md/md.c     |   16 +++++++++++++---
 drivers/md/raid5.c  |    2 +-
 3 files changed, 15 insertions(+), 5 deletions(-)
(Continue reading)

Permalink | Reply | 0 comments |
headers
NeilBrown | 31 Aug 2011 09:38
Picon
Gravatar

Re: dirty chunks on bitmap not clearing (RAID1)

On Mon, 29 Aug 2011 11:30:56 -0500 Chris Pearson <kermit4 <at> gmail.com> wrote:

> I have the same problem.  3 chunks are always dirty.
> 
> I'm using 2.6.38-8-generic and mdadm - v3.1.4 - 31st August 2010
> 
> If that's not normal, then maybe what I've done differently is that I
> created the array, raid 1, with one live and one missing disk, then
> added the second one later after writing a lot of data.
> 
> Also, though probably not the cause, I continued writing data while it
> was syncing, and a couple times during the syncing, both drives
> stopped responding and I had to power off.
> 
> # cat /proc/mdstat
> Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5]
> [raid4] [raid10]
> md127 : active raid1 sdd1[0] sdc1[2]
>       1904568184 blocks super 1.2 [2/2] [UU]
>       bitmap: 3/15 pages [12KB], 65536KB chunk
> 
> unused devices: <none>
> 
> # mdadm -X /dev/sd[dc]1
>         Filename : /dev/sdc1
>            Magic : 6d746962
>          Version : 4
>             UUID : 43761dc5:4383cf0f:41ef2dab:43e6d74e
>           Events : 40013
>   Events Cleared : 40013
(Continue reading)

Permalink | Reply | 4 comments |
headers
CoolCold | 31 Aug 2011 11:05
Picon
Gravatar

Re: possible bug - bitmap dirty pages status

On Sat, Aug 27, 2011 at 1:58 PM, CoolCold <coolthecold <at> gmail.com> wrote:
> Hello!
> I have raid1 array with bitmap (md3), one disk has died, been replaced
> and array resynced:
>
> Aug 25 15:38:03 gamma2 kernel: [    5.986791] md: md3 stopped.
> Aug 25 15:38:03 gamma2 kernel: [    6.043306] raid1: raid set md3
> active with 1 out of 2 mirrors
> Aug 25 15:38:03 gamma2 kernel: [    6.044378] md3: bitmap initialized
> from disk: read 2/2 pages, set 357 bits
> Aug 25 15:38:03 gamma2 kernel: [    6.044442] created bitmap (22
> pages) for device md3
> Aug 25 15:38:03 gamma2 kernel: [    6.070492] md3: detected capacity
> change from 0 to 1478197903360
> Aug 25 15:38:03 gamma2 kernel: [    6.070862]  md3: unknown partition table
> Aug 26 19:33:33 gamma2 kernel: [100325.814179] md: md3: recovery done.
>
> Now, /proc/mdstats still shows "dirty" bitmap, 16 of 22 pages:
>
> root <at> gamma2:~# cat /proc/mdstat
> Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
> md3 : active raid1 sdc3[1] sdb3[0]
>      1443552640 blocks [2/2] [UU]
>      bitmap: 16/22 pages [64KB], 32768KB chunk
>
> root <at> gamma2:~# mdadm -D /dev/md3
> /dev/md3:
>        Version : 00.90
>  Creation Time : Wed Oct 13 03:13:52 2010
>     Raid Level : raid1
(Continue reading)

Permalink | Reply | 9 comments |
headers
Villalobos, Magdalena | 31 Aug 2011 12:49

FELICITATION!!

You have been awarded 700,000.00 pounds in the EXXON MOBIL 2011 raffle for claims Contact Dr. Harry
Longwell on Email: exxoncare <at> hotmail.com for more information
--
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
Permalink | Reply | 0 comments |

Gmane