All of lore.kernel.org
 help / color / mirror / Atom feed
From: Albert Pauw <albert.pauw@gmail.com>
To: NeilBrown <neilb@suse.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: mdadm ddf questions
Date: Fri, 25 Feb 2011 18:53:38 +0100	[thread overview]
Message-ID: <4D67ECA2.2020201@gmail.com> (raw)
In-Reply-To: <20110223171712.09509f9e@notabene.brown>

  Hi Neil,

I investigated a bit further, and here are my findings:

Looking at /proc/mdstat I see the following:

- When I create a ddf containter with a name (say /dev/md0), I stop it 
and start it again, the name has always changed to /dev/md127,
don't know if this is intentional.
- After creating the containter, all disks are marked as spare, 
designated with the (S) ending. However, when I put a disk in an array, it
still stays marked as (S) in the containter entry in /proc/mdstat. I 
think those disks should be branded (S) anymore.
- When I fail a disk, it is kicked out of the array, effectively back 
into the container. However this does not always work, e.g. when I 
created two arrays in the container and
fail a disk of the second array, this does not happen.
- A failed disk stays marked (S) in the container, I think it should now 
be marked (F).

Looking at the end of the output of mdadm -E /dev/md127 I see the disks 
in a table, with a unique serial nr, the devicename and the status.
A freshly created container contains all disks marked as 
GlobalSpare/Online. Adding a disk to an array marks it as active/Online. 
So far so good.

- When I fail a disk, it is marked as active/Online, Failed. A bit 
confusing as it has failed it cannot be active. When I fail a second 
disk, the status
stays active/Online. Only when I stop the arrays and container and 
restart it (mdadm -A -s) it gets marked as failed.
- When I remove a failed disk from the containter, the entry for the 
disk stays online in the mdadm -E output, only the device file is 
removed, but the disk is still marked active/Online, Failed.
I think this whole entry should be removed.
- When I add the disk again, it slots in its old entry, and is still 
marked active/Online, Failed, apart from active/Online bit I agree, the 
disk had failed anyway.
- But when I zero the superblock (mdadm --zero-superblock /dev/sdb) and 
then add it, I get a new entry in the container, which now contains an 
extra entry
apart from the old entry with not device mentioned. This makes sense 
(effectively I added a "new" disk) but the old entry should have been 
removed.

I have also encountered the fact that the same disk was used as a spare 
disk in two arrays created in the containter. In other words, /dev/md1 
failed -> disk replaced,
after that /dev/md2 failed -> same spare disk used for replacement. How odd.

If I assume that the output of mdadm -E (especially the disk entries at 
the end) isl taken from the superblock(s) it looks like these are not 
updated correctly.

I also noticed that a RAID5 array created in a containter cannot be 
expanded with another disk (option -G) as it can in normal setup (i.e. 
without using the container).
The same hold for a RAID1 where you cannot add a third disk.

I hope this gives you more clues about a possible fix?

Cheers,

Albert

On 02/23/11 07:17 AM, NeilBrown wrote:
> On Tue, 22 Feb 2011 08:41:02 +0100 Albert Pauw<albert.pauw@gmail.com>  wrote:
>
>> When I removed the correct disk, which can only be done from the container:
>>
>> mdadm -r /dev/md127 /dev/sdb
>>
>> the command mdadm -E /dev/md127 showed the 5 disks, the entry for sdb
>> didn't had a device but was still
>> "active/Online" and sdd was marked Failed:
> .....
>
>> So it looks like there are some errors in here.
>>
> Indeed it does.  Thank you for putting some time in to testing and producing
> an excellent problem report.
> I have not put as much time into testing and polishing the DDF implementation
> as I would have liked, partly because there doesn't really seem to be much
> interest.
> But reports like this make it a whole lot more interesting.
>
> I will try to look at this some time soon and let you know what I find in the
> code - feel free to remind me if you haven't heard in a week.
>
> Thanks,
> NeilBrown
>
>


  reply	other threads:[~2011-02-25 17:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-19 11:13 mdadm ddf questions Albert Pauw
2011-02-22  7:41 ` Albert Pauw
2011-02-23  6:17   ` NeilBrown
2011-02-25 17:53     ` Albert Pauw [this message]
2011-03-02 22:31       ` NeilBrown
2011-03-10  8:34         ` More ddf container woes Albert Pauw
2011-03-11 11:50           ` Albert Pauw
2011-03-14  8:02             ` NeilBrown
2011-03-14  9:00               ` Albert Pauw
2011-03-15  4:43                 ` NeilBrown
2011-03-15 19:07                   ` Albert Pauw
2011-03-02 22:26   ` mdadm ddf questions NeilBrown
2011-03-02 22:11 ` NeilBrown
2011-03-04  7:52   ` Albert Pauw

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D67ECA2.2020201@gmail.com \
    --to=albert.pauw@gmail.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.