All of lore.kernel.org
 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 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.