[openstack-dev] [Ironic] RAID interface - backing disk hints

Victor Lowther victor.lowther at gmail.com
Thu Jan 22 21:18:30 UTC 2015


On Thu, Jan 22, 2015 at 1:44 AM, Tim Bell <Tim.Bell at cern.ch> wrote:
>> -----Original Message-----
>> From: Victor Lowther [mailto:victor.lowther at gmail.com]
>> Sent: 21 January 2015 21:06
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [Ironic] RAID interface - backing disk hints
>>
>> On Tue, Jan 20, 2015 at 8:36 AM, Jim Rollenhagen <jim at jimrollenhagen.com>
>> wrote:
>> > On Tue, Jan 20, 2015 at 07:28:46PM +0530, Ramakrishnan G wrote:
> ...
>>
>> Given that, deciding to build and manage arrays based on drive
>> mfgr/model/firmware is a lot less useful than deciding to build and manage
>> them based on interface type/media type/size/spindle speed/slot#.
>>
>
> +1 - How about using the /dev/disk/by-path information which says to install the system onto the disks by their device location.
>
> Have a look at how kickstart does it.  It's the same problem so we don't need to re-invent the wheel.

I am aware of how kickstart detects disks and how we can pass
information about which disk to install on, and that is only
tangentially related to what I am talking about.

What I have been talking about is how to decide which physical disks
attached to a hardware RAID controller should be used to create a RAID
volume, and the relative usefulness of the properties of the physical
disks in doing so.  My contention is that drive mfgr/model/firmware is
not used in practice to make that decision -- other factors, such as
disk size, spindle speed, media type, and interface type are what are
used in a production setting.

>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list