Hi,
I've been thinking about $SUBJECT lately, and I would like to propose the following way to handle this:
1) Make the use of mdraid or dmraid for BIOS-raid supported by both configurable both in anaconda (it already is) and in the installed OS (so in relevant udev rules and / or in rc.sysinit).
anaconda will have a cmdline option to override the defaults, and the installed system will have a /etc/sysconfig/biosraid file, with a single setting: PREFERRED_BIOSRAID_HANDLER
Which can be either dmraid or mdraid
2) On a fresh install anaconda will use mdraid and will write "PREFERRED_BIOSRAID_HANDLER=mdraid" to /etc/sysconfig/biosraid (unless forced to use dmraid through the command line)
3) On an update anaconda will look for /etc/sysconfig/biosraid, and use what ever is there, if the file does not exist (as it will not an an upgrade from F-11), it will use dmraid as we did in previous releases and write "PREFERRED_BIOSRAID_HANDLER=dmraid" to /etc/sysconfig/biosraid, so that future upgrades will still use dmraid.
This will result in an it just works experience for users, and offers the ability to keep using dmraid for BIOS-raid supported by path, which is something several people have indicated they want.
The only hole I can poke into this is yum update's from F-11, but we can document what to do on the yum upgrade wiki page, which people doing yum upgrade's should always read.
Regards,
Hans
Hans de Goede (hdegoede@redhat.com) said:
I've been thinking about $SUBJECT lately, and I would like to propose the following way to handle this:
Make the use of mdraid or dmraid for BIOS-raid supported by both configurable both in anaconda (it already is) and in the installed OS (so in relevant udev rules and / or in rc.sysinit).
anaconda will have a cmdline option to override the defaults, and the installed system will have a /etc/sysconfig/biosraid file, with a single setting: PREFERRED_BIOSRAID_HANDLER
Which can be either dmraid or mdraid
... why do we want to do this? Supporting two entirely separate code paths for a single device is *bad*.
Bill
Hi,
On 06/30/2009 11:08 PM, Bill Nottingham wrote:
Hans de Goede (hdegoede@redhat.com) said:
I've been thinking about $SUBJECT lately, and I would like to propose the following way to handle this:
Make the use of mdraid or dmraid for BIOS-raid supported by both configurable both in anaconda (it already is) and in the installed OS (so in relevant udev rules and / or in rc.sysinit).
anaconda will have a cmdline option to override the defaults, and the installed system will have a /etc/sysconfig/biosraid file, with a single setting: PREFERRED_BIOSRAID_HANDLER
Which can be either dmraid or mdraid
... why do we want to do this? Supporting two entirely separate code paths for a single device is *bad*.
Because we will need both code paths anyways as for some bios-raid's mdraid will be the preferred method, while others will only be supported by dmraid.
Given that we need the 2 code paths anyways, making which one to use configurable when both support the type of bios-raid is much easier, and certainly much less error prone, then trying to handle device name changes when upgrading.
Regards,
Hans
Hans de Goede (hdegoede@redhat.com) said:
... why do we want to do this? Supporting two entirely separate code paths for a single device is *bad*.
Because we will need both code paths anyways as for some bios-raid's mdraid will be the preferred method, while others will only be supported by dmraid.
Sure, you have to keep dmraid around for some legacy BIOSes, but...
Given that we need the 2 code paths anyways, making which one to use configurable when both support the type of bios-raid is much easier, and certainly much less error prone, then trying to handle device name changes when upgrading.
This means that for users of a particular BIOS, you get to write "If X, do Y. If A, do B" sort of docs, which are always bad. You get to wire distro-specific magic into anaconda, rc.sysinit, mkinitrd, dracut, etc., etc. You ensure that the old, dead, no longer maintained support for whichever tool is non-default for a format can never be turned off. And you require the user to pass magic options anyway.
It's best to just cut the cord for people who need to migrate. It's a one-time user cost, as opposed to an ongoing maintenance cost.
Bill
On 06/30/2009 11:36 PM, Bill Nottingham wrote:
Hans de Goede (hdegoede@redhat.com) said:
... why do we want to do this? Supporting two entirely separate code paths for a single device is *bad*.
Because we will need both code paths anyways as for some bios-raid's mdraid will be the preferred method, while others will only be supported by dmraid.
Sure, you have to keep dmraid around for some legacy BIOSes, but...
Given that we need the 2 code paths anyways, making which one to use configurable when both support the type of bios-raid is much easier, and certainly much less error prone, then trying to handle device name changes when upgrading.
This means that for users of a particular BIOS, you get to write "If X, do Y. If A, do B" sort of docs, which are always bad. You get to wire distro-specific magic into anaconda, rc.sysinit, mkinitrd, dracut, etc., etc. You ensure that the old, dead, no longer maintained support for whichever tool is non-default for a format can never be turned off.
Erm:
And you require the user to pass magic options anyway.
Only if the user wants to deviate from the default in a fresh install, in all other cases things will just work.
It's best to just cut the cord for people who need to migrate. It's a one-time user cost, as opposed to an ongoing maintenance cost.
So you propose we just release note this and be done with it ?
Regards,
Hans
On Tuesday, June 30 2009, Hans de Goede said:
On 06/30/2009 11:08 PM, Bill Nottingham wrote:
Hans de Goede (hdegoede@redhat.com) said:
I've been thinking about $SUBJECT lately, and I would like to propose the following way to handle this:
Make the use of mdraid or dmraid for BIOS-raid supported by both configurable both in anaconda (it already is) and in the installed OS (so in relevant udev rules and / or in rc.sysinit).
anaconda will have a cmdline option to override the defaults, and the installed system will have a /etc/sysconfig/biosraid file, with a single setting: PREFERRED_BIOSRAID_HANDLER
Which can be either dmraid or mdraid
... why do we want to do this? Supporting two entirely separate code paths for a single device is *bad*.
Because we will need both code paths anyways as for some bios-raid's mdraid will be the preferred method, while others will only be supported by dmraid.
Given that we need the 2 code paths anyways, making which one to use configurable when both support the type of bios-raid is much easier, and certainly much less error prone, then trying to handle device name changes when upgrading.
I'm with Bill here. We just need to suck it up and have people pay the migration cost rather than us having to maintain (and test!) both paths in perpetuity.
In addition, I might even go a step further and say "if mdraid is the way for bios raid, then someone needs to add support for more formats and we remove dmraid entirely". Having both of them was bad enough when it was biosraid vs entirely swraid. Having both with mdadm handling _some_ bios raid is just insanity.
Jeremy
Hi,
On 07/01/2009 12:09 AM, Jeremy Katz wrote:
On Tuesday, June 30 2009, Hans de Goede said:
On 06/30/2009 11:08 PM, Bill Nottingham wrote:
Hans de Goede (hdegoede@redhat.com) said:
I've been thinking about $SUBJECT lately, and I would like to propose the following way to handle this:
Make the use of mdraid or dmraid for BIOS-raid supported by both configurable both in anaconda (it already is) and in the installed OS (so in relevant udev rules and / or in rc.sysinit).
anaconda will have a cmdline option to override the defaults, and the installed system will have a /etc/sysconfig/biosraid file, with a single setting: PREFERRED_BIOSRAID_HANDLER
Which can be either dmraid or mdraid
... why do we want to do this? Supporting two entirely separate code paths for a single device is *bad*.
Because we will need both code paths anyways as for some bios-raid's mdraid will be the preferred method, while others will only be supported by dmraid.
Given that we need the 2 code paths anyways, making which one to use configurable when both support the type of bios-raid is much easier, and certainly much less error prone, then trying to handle device name changes when upgrading.
I'm with Bill here. We just need to suck it up and have people pay the migration cost rather than us having to maintain (and test!) both paths in perpetuity.
Actually testing is an other reason why it would want to have this configurable, so that I and Joel and others with Intel hardware can still test the anaconda / dracut dmraid path.
Also I'm a bit confused now, when I proposed to just release note this you were not in favor because we had already inflicted enough pain on bios raid users in previous releases. Now I come up with a solution to make this work seamlessly, and then we just need to suck it up ??
Regards,
Hans
On Wednesday, July 01 2009, Hans de Goede said:
On 07/01/2009 12:09 AM, Jeremy Katz wrote:
I'm with Bill here. We just need to suck it up and have people pay the migration cost rather than us having to maintain (and test!) both paths in perpetuity.
Actually testing is an other reason why it would want to have this configurable, so that I and Joel and others with Intel hardware can still test the anaconda / dracut dmraid path.
But if most users are testing it with non-Intel hardware, then we need to be doing the same. Otherwise, quirks of the specific hardware format could leak in and break things (or keep them working for you). I don't really see that as a solid reason
Also I'm a bit confused now, when I proposed to just release note this you were not in favor because we had already inflicted enough pain on bios raid users in previous releases. Now I come up with a solution to make this work seamlessly, and then we just need to suck it up ??
I don't remember the explicit case you're referring to, but I expect that I mostly was just lamenting the fact that "bios raid" has continuously been a source of pain and that this is more. Throwing random config things which have to be twiddled into the boot path don't really reduce the pain for the users (what do we set it to for the live image, eg?) and it just increases the maintenance pain
Jeremy
anaconda-devel@lists.stg.fedoraproject.org