On Tue, Jan 20, 2015 at 8:36 AM, Jim Rollenhagen <j...@jimrollenhagen.com> wrote: > On Tue, Jan 20, 2015 at 07:28:46PM +0530, Ramakrishnan G wrote: >> Hi All,
>> I would like to hear everyone's thoughts and probably reach a conclusion of >> whether be open to include more criteria or not. > > I think these filters make sense. An operator may want to say "RAID all > disks of this model"; that's completely reasonable. It is? Do you know any operators who have actually done that in production? I have never heard of it. In my experience, operators only care about hard drive mfgr/model/firmware rev for actuarial reasons, not when building and rebuilding arrays. When it comes to creating arrays and rebuilding them, what matters more is media type, interface type and speed, size, slot#, and spindle speed. More to the point, the exact make/model/firmware rev of disks in the system will change over its lifetime as drives fail and get replaced -- the default drive replacement policy at Dell (and, I would expect, most server vendors) is that you get a compatible replacement with the same or better specs, and getting a drive of the same model from the same manufacturer with the same firmware rev is not guaranteed -- if you ask and if any are in stock, it might happen, but when I did support most people just did not care as long as the replacement was there within 4 hours. 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#. > We've already decided we want to implement the same filters for deciding > which disk to put the root on[0], and so we'll need to write this code > for most/all drivers anyway. We can simply re-use this code for the RAID > use case. Not really -- there is no expectation that the operating system can see the mfgr/make/firmware of the physical disks that make up a virtual disk. What you see instead from the OS side is made up by the RAID controller (and if you are lucky it will be the same value as what you see from whatever you are using to manage the RAID array, but there is no expectation that it works that way), and assuming it reflects the physical disks making up the array is just wrong. To make things even more interesting, you cannot even assume that the interface you will use to create the virtual disk will return a unique identifier for that virtual disk that corresponds to anything you will see on the OS side -- that is an issue that we are having to work around for the RAID interfaces that the DRAC exposes. Sad to say, the only real thing you can count on for picking the right raid volume for a root device knowing what size it should be (or) always creating the virtual disk for the root array first, choosing /dev/sda and hoping your RAID controller exposes devices in the order in which they were created. If you are not using RAID then using mfgr/model/firmware/serial# composed together to make a unique identifier makes sense. If you are using RAID it does not because there is no expectation that information is exposed to the OS at all. > // jim > > [0] > http://specs.openstack.org/openstack/ironic-specs/specs/kilo/root-device-hints.html > >> >> Please pour in your thoughts on the thread >> >> Regards, >> Ramakrishnan (irc: rameshg87) > >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
