Путеводитель по Руководству Linux

  User  |  Syst  |  Libr  |  Device  |  Files  |  Other  |  Admin  |  Head  |



   mdadm    ( 8 )

управлять MD-устройствами, также известными как Linux Software RAID (manage MD devices aka Linux Software RAID)

ASSEMBLE MODE

Usage: mdadm --assemble md-device options-and-component- devices...

Usage: mdadm --assemble --scan md-devices-and-options...

Usage: mdadm --assemble --scan options...

This usage assembles one or more RAID arrays from pre-existing components. For each array, mdadm needs to know the md device, the identity of the array, and a number of component-devices. These can be found in a number of ways.

In the first usage example (without the --scan) the first device given is the md device. In the second usage example, all devices listed are treated as md devices and assembly is attempted. In the third (where no devices are listed) all md devices that are listed in the configuration file are assembled. If no arrays are described by the configuration file, then any arrays that can be found on unused devices will be assembled.

If precisely one device is listed, but --scan is not given, then mdadm acts as though --scan was given and identity information is extracted from the configuration file.

The identity can be given with the --uuid option, the --name option, or the --super-minor option, will be taken from the md- device record in the config file, or will be taken from the super block of the first component-device listed on the command line.

Devices can be given on the --assemble command line or in the config file. Only devices which have an md superblock which contains the right identity will be considered for any array.

The config file is only used if explicitly named with --config or requested with (a possibly implicit) --scan. In the later case, /etc/mdadm.conf or /etc/mdadm/mdadm.conf is used.

If --scan is not given, then the config file will only be used to find the identity of md arrays.

Normally the array will be started after it is assembled. However if --scan is not given and not all expected drives were listed, then the array is not started (to guard against usage errors). To insist that the array be started in this case (as may work for RAID1, 4, 5, 6, or 10), give the --run flag.

If udev is active, mdadm does not create any entries in /dev but leaves that to udev. It does record information in /run/mdadm/map which will allow udev to choose the correct name.

If mdadm detects that udev is not configured, it will create the devices in /dev itself.

In Linux kernels prior to version 2.6.28 there were two distinctly different types of md devices that could be created: one that could be partitioned using standard partitioning tools and one that could not. Since 2.6.28 that distinction is no longer relevant as both type of devices can be partitioned. mdadm will normally create the type that originally could not be partitioned as it has a well defined major number (9).

Prior to 2.6.28, it is important that mdadm chooses the correct type of array device to use. This can be controlled with the --auto option. In particular, a value of "mdp" or "part" or "p" tells mdadm to use a partitionable device rather than the default.

In the no-udev case, the value given to --auto can be suffixed by a number. This tells mdadm to create that number of partition devices rather than the default of 4.

The value given to --auto can also be given in the configuration file as a word starting auto= on the ARRAY line for the relevant array.

Auto Assembly When --assemble is used with --scan and no devices are listed, mdadm will first attempt to assemble all the arrays listed in the config file.

If no arrays are listed in the config (other than those marked <ignore>) it will look through the available devices for possible arrays and will try to assemble anything that it finds. Arrays which are tagged as belonging to the given homehost will be assembled and started normally. Arrays which do not obviously belong to this host are given names that are expected not to conflict with anything local, and are started "read-auto" so that nothing is written to any device until the array is written to. i.e. automatic resync etc is delayed.

If mdadm finds a consistent set of devices that look like they should comprise an array, and if the superblock is tagged as belonging to the given home host, it will automatically choose a device name and try to assemble the array. If the array uses version-0.90 metadata, then the minor number as recorded in the superblock is used to create a name in /dev/md/ so for example /dev/md/3. If the array uses version-1 metadata, then the name from the superblock is used to similarly create a name in /dev/md/ (the name will have any 'host' prefix stripped first).

This behaviour can be modified by the AUTO line in the mdadm.conf configuration file. This line can indicate that specific metadata type should, or should not, be automatically assembled. If an array is found which is not listed in mdadm.conf and has a metadata format that is denied by the AUTO line, then it will not be assembled. The AUTO line can also request that all arrays identified as being for this homehost should be assembled regardless of their metadata type. See mdadm.conf(5) for further details.

Note: Auto assembly cannot be used for assembling and activating some arrays which are undergoing reshape. In particular as the backup-file cannot be given, any reshape which requires a backup- file to continue cannot be started by auto assembly. An array which is growing to more devices and has passed the critical section can be assembled using auto-assembly.