Raid system confusion

lilsirecho · 2009-08-26 15:12:38

Perhaps I have read too many articles on raid and mdadm such as to be unable to sort out truth from fiction.

The mdadm system is purported to be using /etc/mdadm.conf to establish a raid array that will autostart when booting. Fstab is used to setup a mount for the resulting MD raid array.

Rather obscure in the readings is the need to establish the raid array when using mdadm and run:

mdadm -D --scan >> /etc/mdadm.conf

mdadm -E --scan >> /etc/mdadm.conf

This establishes the array(s) in /etc/mdadm.conf which can be auto-installed during boot using the array data from that file.

In the wiki for raid installs, mention is made to insert MODULES in mkinitcpio, and run :

mkinitcpio -p kernel26

Within the config file for the kernel are the following configs:(among others)

 CONFIG_BLK_DEV_MD=m
            CONFIG_MD_RAID0=m
             CONFIG_MD=y

As is shown, the config for MD is enabled.

The use of the other two is not apparent after examining many references on the subject of raid.

RAID as a system command has been deprecated.

Much of the reference material seems RAID system related as opposed to MDADM.

Further confusion results when MSDOS nomenclature enters the scene in the form of 0XFD.

This term when applied to raid arrays provides four partitions on each device which can be autodetected (using the FD term for detection).

I do not recall in the literature any reference to using such FD autodetect in MDADM since it derives the raid data from /etc/mdadm.conf. Therein it may find FD data but it would not be necessary for auto starting but would set up partioned arrays rather than full device arrays.

Going back to the " CONFIG MODULES", what are these for and when are they to be utilized?

Will including them in mkinitcpio MODULES be sufficient to AUTODETECT a RAID0 array without using 0XFD for an ID?

Do these MODULES have any connection to MDADM raid systems?

Does arch have backward provisions for RAID as opposed to MDADM?

Is there an AUTODETECT for MDADM as opposed to AUTOSTART (provided by /etc/mdadm.conf)? Does AUTODETECT provide auto-assembling of a given array as defined by "CONFIG MODULES"?

As stated previously the wiki refers to adding MODULES to mkinitcpio for MDADM raid systems...for what purpose?

Confusion there is.....................

fukawi2 · 2009-08-26 22:50:25

lilsirecho wrote:

Do these MODULES have any connection to MDADM raid systems?

Kernel Modules and mkinitcpio modules are two different things. The default kernel (kernel26) package has support for RAID compiled in as a kernel module. You need to add the 'mdadm' or 'raid' (depreciated) hook into mkinitcpio.conf then run mkinitcpio.conf -p kernel26 to get it working.

lilsirecho wrote:

Does arch have backward provisions for RAID as opposed to MDADM?

mdadm is RAID, just a software implmentation in the Linux kernel, as opposed to hardware RAID or other software implementations in other O/S'es.

lilsirecho · 2009-08-27 04:00:16

In the mdadm raid wiki, mdadm has reference to adding modules to mkinitcpio (understood to be related to the raid system).

I know that RAID can be hardware raid (expensive) and that mdadm is software raid.

There are many queries in my post yet to be answered..................

fukawi2 · 2009-08-27 07:05:31

lilsirecho wrote:

Going back to the " CONFIG MODULES", what are these for and when are they to be utilized?

They are the kernel modules. They handle the Software RAID implementation within the kernel.

lilsirecho wrote:

Will including them in mkinitcpio MODULES be sufficient to AUTODETECT a RAID0 array without using 0XFD for an ID?

You do not need to include these modules in mkinitcpio.conf
Adding the 'mdadm' hook to mkinitcpio.conf will support "autodetection" (using /etc/mdadm.conf)

lilsirecho wrote:

Do these MODULES have any connection to MDADM raid systems?

Yes.

lilsirecho wrote:

Is there an AUTODETECT for MDADM as opposed to AUTOSTART (provided by /etc/mdadm.conf)? Does AUTODETECT provide auto-assembling of a given array as defined by "CONFIG MODULES"?

I'm not sure what you mean by "CONFIG MODULES" in this context - I'm assuming the kernel modules mentioned before, but there's no provision there for 'defining' your RAID arrays. AFAIK there's no fully automatic detection and activation for RAID arrays.

lilsirecho wrote:

As stated previously the wiki refers to adding MODULES to mkinitcpio for MDADM raid systems...for what purpose?

I'm not sure exactly which wiki page you're referring to - there isn't one titled exactly 'mdadm' but there's several that deal with mdadm in various aspects. I've only seen adding 'mdadm' hook to mkinitcpio but I might have missed something.

Can I ask, are you asking how to implement your solution to a problem, rather than just for a solution to a problem?

Last edited by fukawi2 (2009-08-27 07:05:51)

lilsirecho · 2009-08-27 16:23:01

This is the listing in wiki for mkiniicpio...mdadm raid:

mdadm      This hook supersedes the above raid hook. It supports assembling the arrays from /etc/mdadm.conf, or autodetection during boot      Loads the necessary modules for software raid devices, and assembles the raid devices when run. See the section Customizing the kernel command line for further configuration.

MODULES: is an item in mkinitcpio and the modules I mentioned are in the kernel for software raid devices....thus the connection is made.

The actual condition for mdadm to run is to have the file /etc/mdadm.conf populated with raid data. This is not apparent in the notes above.

The note states....."It supports assembling the arrays from /etc/mdadm.conf or autodetection during boot"

This statement implies an alternate "autodetect" instead of "/etc/mdadm.conf" file. Thus the use of the MODULES in mkinitcpio seems to allow "autodetect" since it is the only source available for raid info in the absence of /etc/mdadm.conf. The ID for such raid devices is apparently not required with autodetect. (I am aware of the 0xFD ID for partitioned devices but am not discussing partitioned arrays per se).

Reference is made to the "customizing the kernel command line".

This reference states the following:

  Using raid

First add the 'mdadm' hook to the HOOKS list and any required raid modules to the MODULES list in /etc/mkinitcpio.conf.

Kernel Parameters: Using the 'mdadm' hook, you no longer need to configure your RAID array in the GRUB parameters. The 'mdadm' hook will either use your /etc/mdadm.conf file, or automatically detect the arrays during the init phase of boot.

This statement further outlines a second approach to "autodetect" the raid array(s).

The need to populate the file "/etc/mdadm.conf" is not emphasized and needs to be referenced to make the procedure complete; just as the reference to "kernel command line" has been included.

I find the statement within the "kernel command line" reference to outline an"autodetect" mode for mdadm raid and calls for modules in mkinitcpio. Modules therein is assumed to be kernel modules since this is a kernel command line reference. It would seem that the command line can be modified to cause autodetection if the right MODULES are included in mkinitcpio.

Thus, there seems to be some confusion...........

EDIT: The following discussion introduces even more confusion to the raid system setup and assembling:

https://www.sevenl.net/blog/installing- … d-and-ssh/

Possibly, this system applies only to 0XFD partitioned devices but it is not apparent just what it does cover.

It seems to make a combination of RAID and MDADM procedures but this isn't completely clear either!!!!

I intend to try :

MODULES: "modprobe=raid0" in mkinitcpio.conf with no /etc/mdadm.conf file data.

Last edited by lilsirecho (2009-08-27 20:07:52)

lilsirecho · 2009-08-27 20:31:44

Removed the raid data for array md0 from /etc/mdadm.conf.....

Entered into mkinitcpio.conf MODULES:

MODULES="raid0"

Left the mdadm entry in HOOKS:

Rebooted ...

Raid0 array of three devices was autodetected and mounted thru Fstab.

Rebooted again and same result.

Verified that /etc/mdadm.conf file does not have raid0 data.

Autodetect of raid devices is therfore possible in this kernel(latest).

If I haven't skipped over some detail?

fukawi2 · 2009-08-27 22:50:57

I stand corrected then, the mdadm hook is even better than I already thought it was

RAID-0 is probably the simplest of RAID's for the system to autodetect. I wonder if it would work with -1 or -5.

I agree the part of the wiki that you've quoted is a bit confusing, mixing the 'mdadm' hook and kernel configuration line stuff together. AFAIK, the adding configuration parameter to the kernel line in GRUB is only required if you're using the 'raid' hook instead of 'mdadm'

lilsirecho · 2009-08-27 23:06:30

I have been trying to reproduce the action with no success, however, after deleting MD0.

One thing is showing up...inconsistent ID for the scsi devices.

However, initially I was able to reboot many times with MD0 mounted every time. This with no array listed in /etc/mdadm.conf.

Further, the usual indicator for raid start, which occured with /etc/mdadm.conf file present, did not appear in the start up messages. The raid array was present after reaching Desktop.

Perhaps this suggests autodetect has occured.

It could be a freak thing.

I have to review what I did.

lilsirecho · 2009-08-27 23:42:30

Revisited the whole scene and reproduced the condition for what might be autostart. The key to the arrangement has to do with the sequence of events.

I assembled md0 and mounted it in /mnt/md.

I ran mdadm -D --scan >> /etc/mdadm.conf

Verified the array data present in /etc/mdadm.conf.

Ran mkinitcpio -p kernel26.

This had a comment to the effect that /etc/mdadm.conf would assemble the array.

Then I manually deleted the array data from /etc/mdadm.conf , saved and exit the file.

Rebooted with the raid array mounted in /mnt/md.

No raid messages were noted in the boot sequence.

I am checking dmesg for some info on md0......

bash-4.0# dmesg |grep md0
md: md0 stopped.
md0: setting max_sectors to 128, segment boundary to 32767
 md0: unknown partition table
EXT3 FS on md0, internal journal
bash-4.0#

No further data discovered.

lilsirecho · 2009-08-28 01:03:17

Removed /etc/mdadm.conf to trash bin following the note observed in mdadm.conf:

mdadm will function properly without the use of a configuration file,
# but this file is useful for keeping track of arrays and member disks.
# In general, a mdadm.conf file is created, and updated, after arrays
# are created. This is the opposite behavior of /etc/raidtab which is
# created prior to array construction.

The raid array is again mounted in /mnt/md upon reboot.

This suggests that the array is defined elsewhere in the system as well as the mdadm.conf file/or/it is autodetected.

Cat /proc/mdstat contains:

bash-4.0# cat /proc/mdstat
Personalities : [raid0]
md0 : active raid0 sdb[0] sde[2] sdd[1]
      23837376 blocks 64k chunks

unused devices: <none>
bash-4.0#

The ID's agree with gparted.

lilsirecho · 2009-08-28 01:28:03

This message in mkinitcpio -p kernel26

Custom /etc/mdadm.conf file will be used in initramfs for assembling arrays.

Removed the references to all arrays in /etc/mdadm.conf in a second HDD after running the above.

Rebooted.

lilsirecho · 2009-08-28 02:48:04

The mdadm man page describes the system best.

The mdadm.conf file isn't required as previously mentioned.

The raid array data is provided by /proc/mdstat in the absence of /etc/mdadm.conf.

That explains why I am able to mount md0 without the mdadm.conf file.(Actually, /proc/mdstat probably handles it anyway!).

Still haven't decided on how to autoassemble a raid array w/o 0xFD partitioning.

lilsirecho · 2009-08-28 23:48:45

The result of performing the procedure(s) for mkinitcpio -p kernel26 and then removing /etc/mdadm.conf permits the reboot of mounted md0 raid array.

This is sort of autostart for the raid system since it is independent of the port to which the raid devices are connected.

This has performed correctly in two HDD arrangements using the same raid drives consisting of Compact Flash devices connected thru SataII adapters.

The arrangement calls for assembling the raid array with mdadm, initiating the array data in /etc/mdadm.conf with :

mdadm -D --scan >> /etc/mdadm.conf

Then run:

mkinitcpio -p kernel26

Then place /etc/mdadm.conf in trash bin.

Upon reboot, the raid system will be autostarted and mounted thru fstab.
Changing the ports to which the devices are connected does not abort the autostart. I use the term autostart loosely since the system has pre-knowledge rather than pristine devices not yet assembled within the given system.

I assume the data in /proc/mdstat controls the raid assembly since mdadm searches for raid compatible devices probably by finding them with compatible superblocks. At least that seems to be what is happening. One might say the result is autodetection of previously set up raid devices regardless of the system port(s) utilized by each device of the array. In my case , three devices.

Literature on the raid subject mentions utilizing 0XFD for the autodetection of raid arrays . This 0XFD parameter is included in the device data and serves to provide multiple partitions in raid systems possibly with autodetect capability.

Perhaps I am in error on that point, however.

Guess this is the the best I can do.........

Last edited by lilsirecho (2009-08-28 23:50:45)

lilsirecho · 2009-08-29 16:44:28

It is apparent that initramfs is utilized by mkinitcpio to control the mdadm device arrangement.

Since it seems to acknowledge variations in the device connection ports, I assume it autodetects the devices for a raid array but it is not apparent how it can identify those comprising an array if such assumption is correct.

Perhaps further study?

lilsirecho · 2009-08-29 21:50:00

Performed dmesg as follows:

bash-4.0# dmesg |grep raid0
md: raid0 personality registered for level 0
raid0: looking at sdc                       
raid0:   comparing sdc(15924224)<6> with sdc(15924224)
raid0:   END                                          
raid0:   ==> UNIQUE                                   
raid0: 1 zones                                        
raid0: looking at sdb
raid0:   comparing sdb(16088448)<6> with sdc(15924224)
raid0:   NOT EQUAL
raid0:   comparing sdb(16088448)<6> with sdb(16088448)
raid0:   END
raid0:   ==> UNIQUE
raid0: 2 zones
raid0: looking at sda
raid0:   comparing sda(15662080)<6> with sdc(15924224)
raid0:   NOT EQUAL
raid0:   comparing sda(15662080)<6> with sdb(16088448)
raid0:   NOT EQUAL
raid0:   comparing sda(15662080)<6> with sda(15662080)
raid0:   END
raid0:   ==> UNIQUE
raid0: 3 zones
raid0: FINAL 3 zones
raid0: zone 1
raid0: checking sdc ...<6> contained as device 0
raid0: checking sda ...<6> nope.
raid0: checking sdb ...<6> contained as device 1
raid0: zone->nb_dev: 2, sectors: 524288
raid0: current zone start: 15924224
raid0: zone 2
raid0: checking sdc ...<6> nope.
raid0: checking sda ...<6> nope.
raid0: checking sdb ...<6> contained as device 0
raid0: zone->nb_dev: 1, sectors: 164224
raid0: current zone start: 16088448
raid0: done.
raid0 : md_size is 47674752 sectors.
raid0 : conf->spacing is 524288 sectors.
raid0 : nb_zone is 91.
raid0 : Allocating 728 bytes for hash.
bash-4.0#

So there is a search performed to complete the raid0 personality.

This seems to be an autodetect function, notwithstanding that the array was previously setup with mdadm.

This systematic search occurs even if the devices are re-distributed among the sataII ports.

I assume a number of raid personalities could be included if entered as I have described in previous postings.

Perhaps there is a better description for what is occuring?

lilsirecho · 2009-08-30 00:19:08

During the mkinitcpio -p kernel26 procedure, the notation is displayed stating that mdadm will use /etc/mdadm.conf for assembly...

This seems to be a superfluous entry since I have demonstrated that /etc/mdadm.conf can be sent to the trash and the raid array is assembled anyway. (mdadm note declare that /etc/mdadm.conf isn't necessary and is used for reference of array data).

However, in my setup, I required /etc/mdadm.conf to be populated with the array data with the following:

mdadm -D --scan >> /etc/mdadm.conf

I followed that running mkinitcpio -p kernel26 and then placed /etc/mdadm.conf in the trash bin.

This populated the initramfs via mkinitcpio with a raid0 array personality. But /etc/mdadm.conf is no longer needed and only provided that raid0 parameters had been initiated via mkinitcpio -p kernel26 procedures.

So it seems as I describe it that /etc/mdadm.conf is and isn't required for raid arrays to be recognized at boot time.

What would happen if only raid0 with no devices was declared via .....mdadm -D ..scan >> /etc/mdadm.conf...?

Would mkinitcpio -p kernel26 accept this entry? Would raid0 find the devices during intramfs?''

That would be more like autodetect............

lilsirecho · 2009-09-01 02:13:08

One further observation. With /etc/mdadm.conf file in the trash, running :

mdadm -D --scan >> /etc/mdadm.conf

places the array data in /etc/mdadm.conf, thus it generates the array data needed by mkinitcpio with that command.

No further insight into the raid system was encountered.

Arch Linux

#1 2009-08-26 15:12:38

Raid system confusion

#2 2009-08-26 22:50:25

Re: Raid system confusion

#3 2009-08-27 04:00:16

Re: Raid system confusion

#4 2009-08-27 07:05:31

Re: Raid system confusion

#5 2009-08-27 16:23:01

Re: Raid system confusion

#6 2009-08-27 20:31:44

Re: Raid system confusion

#7 2009-08-27 22:50:57

Re: Raid system confusion

#8 2009-08-27 23:06:30

Re: Raid system confusion

#9 2009-08-27 23:42:30

Re: Raid system confusion

#10 2009-08-28 01:03:17

Re: Raid system confusion

#11 2009-08-28 01:28:03

Re: Raid system confusion

#12 2009-08-28 02:48:04

Re: Raid system confusion

#13 2009-08-28 23:48:45

Re: Raid system confusion

#14 2009-08-29 16:44:28

Re: Raid system confusion

#15 2009-08-29 21:50:00

Re: Raid system confusion

#16 2009-08-30 00:19:08

Re: Raid system confusion

#17 2009-09-01 02:13:08

Re: Raid system confusion

Board footer