On 12/01/2009 08:48 AM, Hans de Goede wrote:
> Hi,
>
> On 11/28/2009 02:02 AM, Doug Ledford wrote:
>> On 11/26/2009 04:31 AM, Hans de Goede wrote:
>>> 3) We need to change the not using of a bitmap, we should use a bitmap
>>> by default except when the array will be used for /boot or swap.
>>
>> Correct. The typical /boot array is too small to worry about, it can
>> usually be resynced in its entirety in a matter of seconds. Swap
>> partitions shouldn't use a bitmap because we don't want the overhead of
>> sync operations on the swap subsystem, especially since its data is
>> generally speaking transient. Other filesystems, especially once you
>> get to 10GB or larger, can benefit from the bitmap in the event of an
>> improper shutdown.
>>
>>> Questions:
>>> 1) What commandline option should we pass to "mdadm --create" to
>>> achieve this?
>>
>> --bitmap={none,internal}
Followup on this: --bitmap=internal when we want it, nothing when we
don't. The --bitmap=none option is only valid when changing an array
from having a bitmap to not having one using grow mode, it is not a
valid option to --create.
> Ok, so for /boot we must specify a superblock version, should we use 1.0 or
> 0.9 (I assume 1.0, but confirmation of that would be good).
Yes, 1.0 would be best.
> Then you should have asked us to change this 7 or 8 releases ago, changing
> this so close to RHEL-6 is just not going to happen.
I've been asking to be included in anaconda/md raid planning for a
*LONG* time now. Just because you are not the person I asked, do not
assume the request was not made. It has been made, multiple times, in
person, face to face, and by the time it was time to actually plan
things out, was always forgotten or prioritized to the bottom of the
ladder where nothing happened.
>>> If we can still specify which minor to use when creating a new
>>> array,
>>> even though
>>> that minor may change after the first reboot, then the amount of
>>> changes needed
>>> to the installer are minimal and we can likely do this without
>>> problems for RHEL-6.
>>
>> I don't understand. Please enlighten me as to these requirements on
>> minor numbers in the installer. After all, it's not like there isn't a
>> simple means of naming these things:
>>
>> If md raid device used for lvm pv, name it /dev/md/pv-#
>> If md raid device used for swap, name it /dev/md/swap-#
>> If md raid device used for /, name it /dev/md/root
>> If md raid device used for any other data partition, name it
>> /dev/md/<basename of mount point>
>>
>> And it's not like anaconda doesn't already have that information
>> available when its creating filesystem labels, so I'm curious why it's
>> so hard to use names instead of numbers for arrays in anaconda?
>>
>
> It is not that hard, but currently all mdraid code inside anaconda is
> based on the assumption that they are identified by their minor, changing
> this takes time, time we do not have before RHEL-6.
>
> So fixing this will have to wait till Fedora 14 I'm afraid.
If it even happens then...
> Regards,
>
> Hans
>
> p.s.
>
> Can you please reply to bug 537329 one more time, I've tried to explain
> why I think that we can simplify mdraid activation in the proposed way
> despite your objections. If you insist on keeping things as is, that is
> fine
> too, then I'll come up with a separate solution for the Intel BIOS RAID
> problems the current activation setup causes.
The Intel BIOS RAID problems in that bug report are not unique. In
fact, if you created a new, normal md raid array after installation and
did not enter the array's info in mdadm.conf, it too would fail to be
assembled (unless you hot plugged it after rc.sysinit was done running).
Running mdadm -Eb <constituent device> >> mdadm.conf is simply part of
the normal post-install array creation process for md raid arrays. In
any case, more comments in the bug.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
