Linux RAID subsystem development
 help / color / mirror / Atom feed
From: Martin Wilck <mwilck@arcor.de>
To: NeilBrown <neilb@suse.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: Implementing --detail-platform for DDF
Date: Thu, 12 Sep 2013 20:14:20 +0200	[thread overview]
Message-ID: <5232047C.7030309@arcor.de> (raw)
In-Reply-To: <20130912160043.54d73613@notabene.brown>

On 09/12/2013 08:00 AM, NeilBrown wrote:
> On Wed, 11 Sep 2013 23:00:06 +0200 Martin Wilck <mwilck@arcor.de> wrote:
> 
>> Hi Neil,
>>
>> I thought I might come up with an implementation of mdadm
>> --detail-platform for DDF, but I encountered a problem I'd like to discuss.
>>
>> For DDF, we can't scan PCI devices like IMSM does, because we don't know
>> all controllers supporting DDF. Thus I considered scanning block devices
>> instead and looking at "foreign" vendor strings in the meta data;
>> possibly also filtering by device names or types. It occured to me that
>> it might be elegant to simply call conf_get_devs() for a list of devices
>> to be scanned. But if I do that, config.o and its dependencies must be
>> linked with mdmon, blowing up its size considerably. I figure that
>> that's a no-go. But I'm also reluctant to write my own DDF-specific
>> block device scanning code while there is conf_get_devs() already.
>>
>> Perhaps I am misunderstanding the purpose of --detail-platform?
>> I wouldn't bother with it if YaST2/libstorage didn't call it in order to
>> check if a "fake RAID" platform is present.
>>
>> Regards
>> Martin
> 
> I think it would be wrong for --detail-platform to look at the contents of
> disk drives.  If anything, it must look at the 'platform' - the controller.
>
> If YaST2 uses --detail-platform for anything other than IMSM it is
doing it
> wrong.

The current libstorage logic is as follows:
 1. runs mdadm --detail-platform to see if there is IMSM
    no -> 2, yes -> 3
 2. start dmraid, then mdadm. -> 5
 3. run mdadm -Es to derive a list of array names, and ask user if he
wants to drive these arrays with mdadm  (this will look weird to the
user if the array names are empty).
    no -> 2, yes -> 4
 4. start mdadm, then dmraid
 5. proceed with LVM etc.

> I'm currently building a virtual machine running openSUSE 13.1-M4 with DDF
> devices.  I'll see what yast thinks of it...

You may want to have a look at
https://build.opensuse.org/project/show/home:mwilck:mdadm-DDF:openSUSE

It contains almost-up-to-date mdadm and tentative patches for
libstorage. I successfully installed both OpenSUSE 12.3 and Factory with
these packages on a DUD. The libstorage patch I am using is pretty
simplistic but it does the job.

Martin



  reply	other threads:[~2013-09-12 18:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-11 21:00 Implementing --detail-platform for DDF Martin Wilck
2013-09-12  6:00 ` NeilBrown
2013-09-12 18:14   ` Martin Wilck [this message]
2013-09-13  0:18 ` Dan Williams
2013-09-13 17:25   ` Martin Wilck

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=5232047C.7030309@arcor.de \
    --to=mwilck@arcor.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox