RAID arrays=========== Boot time assembly of RAID arrays--------------------------------- Tools that manage md devices can be found at   https://www.kernel.org/pub/linux/utils/raid/  You can boot with your md device with the following kernel commandlines: for old raid arrays without persistent superblocks::   md=<md device no.>,<raid level>,<chunk size factor>,<fault level>,dev0,dev1,...,devn for raid arrays with persistent superblocks::   md=<md device no.>,dev0,dev1,...,devn or, to assemble a partitionable array::   md=d<md device no.>,dev0,dev1,...,devn ``md device no.``+++++++++++++++++ The number of the md device ================= =========``md device no.`` device================= =========              0		md0	      1		md1	      2		md2	      3		md3	      4		md4================= ========= ``raid level``++++++++++++++ level of the RAID array =============== =============``raid level``  level=============== =============-1		linear mode0		striped mode=============== ============= other modes are only supported with persistent super blocks ``chunk size factor``+++++++++++++++++++++ (raid-0 and raid-1 only) Set  the chunk size as 4k << n. ``fault level``+++++++++++++++ Totally ignored ``dev0`` to ``devn``++++++++++++++++++++ e.g. ``/dev/hda1``, ``/dev/hdc1``, ``/dev/sda1``, ``/dev/sdb1`` A possible loadlin line (Harald Hoyer <HarryH@Royal.Net>)  looks like this:: 	e:\loadlin\loadlin e:\zimage root=/dev/md0 md=0,0,4,0,/dev/hdb2,/dev/hdc3 ro  Boot time autodetection of RAID arrays-------------------------------------- When md is compiled into the kernel (not as module), partitions oftype 0xfd are scanned and automatically assembled into RAID arrays.This autodetection may be suppressed with the kernel parameter``raid=noautodetect``.  As of kernel 2.6.9, only drives with a type 0superblock can be autodetected and run at boot time. The kernel parameter ``raid=partitionable`` (or ``raid=part``) meansthat all auto-detected arrays are assembled as partitionable. Boot time assembly of degraded/dirty arrays------------------------------------------- If a raid5 or raid6 array is both dirty and degraded, it could haveundetectable data corruption.  This is because the fact that it is``dirty`` means that the parity cannot be trusted, and the fact that itis degraded means that some datablocks are missing and cannot reliablybe reconstructed (due to no parity). For this reason, md will normally refuse to start such an array.  Thisrequires the sysadmin to take action to explicitly start the arraydespite possible corruption.  This is normally done with::    mdadm --assemble --force .... This option is not really available if the array has the rootfilesystem on it.  In order to support this booting from such anarray, md supports a module parameter ``start_dirty_degraded`` which,when set to 1, bypassed the checks and will allows dirty degradedarrays to be started. So, to boot with a root filesystem of a dirty degraded raid 5 or 6, use::    md-mod.start_dirty_degraded=1  Superblock formats------------------ The md driver can support a variety of different superblock formats.Currently, it supports superblock formats ``0.90.0`` and the ``md-1`` formatintroduced in the 2.5 development series. The kernel will autodetect which format superblock is being used. Superblock format ``0`` is treated differently to others for legacyreasons - it is the original superblock format.  General Rules - apply for all superblock formats------------------------------------------------ An array is ``created`` by writing appropriate superblocks to alldevices. It is ``assembled`` by associating each of these devices with anparticular md virtual device.  Once it is completely assembled, it canbe accessed. An array should be created by a user-space tool.  This will writesuperblocks to all devices.  It will usually mark the array as``unclean``, or with some devices missing so that the kernel md drivercan create appropriate redundancy (copying in raid 1, paritycalculation in raid 4/5). When an array is assembled, it is first initialized with theSET_ARRAY_INFO ioctl.  This contains, in particular, a major and minorversion number.  The major version number selects which superblockformat is to be used.  The minor number might be used to tune handlingof the format, such as suggesting where on each device to look for thesuperblock. Then each device is added using the ADD_NEW_DISK ioctl.  Thisprovides, in particular, a major and minor number identifying thedevice to add. The array is started with the RUN_ARRAY ioctl. Once started, new devices can be added.  They should have anappropriate superblock written to them, and then be passed in withADD_NEW_DISK. Devices that have failed or are not yet active can be detached from anarray using HOT_REMOVE_DISK.  Specific Rules that apply to format-0 super block arrays, and arrays with no superblock (non-persistent)-------------------------------------------------------------------------------------------------------- An array can be ``created`` by describing the array (level, chunksizeetc) in a SET_ARRAY_INFO ioctl.  This must have ``major_version==0`` and``raid_disks != 0``. Then uninitialized devices can be added with ADD_NEW_DISK.  Thestructure passed to ADD_NEW_DISK must specify the state of the deviceand its role in the array. Once started with RUN_ARRAY, uninitialized spares can be added withHOT_ADD_DISK.  MD devices in sysfs------------------- md devices appear in sysfs (``/sys``) as regular block devices,e.g.::    /sys/block/md0 Each ``md`` device will contain a subdirectory called ``md`` whichcontains further md-specific information about the device. All md devices contain:   level     a text file indicating the ``raid level``. e.g. raid0, raid1,     raid5, linear, multipath, faulty.     If no raid level has been set yet (array is still being     assembled), the value will reflect whatever has been written     to it, which may be a name like the above, or may be a number     such as ``0``, ``5``, etc.   raid_disks     a text file with a simple number indicating the number of devices     in a fully functional array.  If this is not yet known, the file     will be empty.  If an array is being resized this will contain     the new number of devices.     Some raid levels allow this value to be set while the array is     active.  This will reconfigure the array.   Otherwise it can only     be set while assembling an array.     A change to this attribute will not be permitted if it would     reduce the size of the array.  To reduce the number of drives     in an e.g. raid5, the array size must first be reduced by     setting the ``array_size`` attribute.   chunk_size     This is the size in bytes for ``chunks`` and is only relevant to     raid levels that involve striping (0,4,5,6,10). The address space     of the array is conceptually divided into chunks and consecutive     chunks are striped onto neighbouring devices.     The size should be at least PAGE_SIZE (4k) and should be a power     of 2.  This can only be set while assembling an array   layout     The ``layout`` for the array for the particular level.  This is     simply a number that is interpreted differently by different     levels.  It can be written while assembling an array.   array_size     This can be used to artificially constrain the available space in     the array to be less than is actually available on the combined     devices.  Writing a number (in Kilobytes) which is less than     the available size will set the size.  Any reconfiguration of the     array (e.g. adding devices) will not cause the size to change.     Writing the word ``default`` will cause the effective size of the     array to be whatever size is actually available based on     ``level``, ``chunk_size`` and ``component_size``.      This can be used to reduce the size of the array before reducing     the number of devices in a raid4/5/6, or to support external     metadata formats which mandate such clipping.   logical_block_size     Configure the array's logical block size in bytes. This attribute     is only supported for 1.x meta. Write the value before starting     array. The final array LBS uses the maximum between this     configuration and LBS of all combined devices. Note that     LBS cannot exceed PAGE_SIZE before RAID supports folio.     WARNING: Arrays created on new kernel cannot be assembled at old     kernel due to padding check, Set module parameter 'check_new_feature'     to false to bypass, but data loss may occur.   reshape_position     This is either ``none`` or a sector number within the devices of     the array where ``reshape`` is up to.  If this is set, the three     attributes mentioned above (raid_disks, chunk_size, layout) can     potentially have 2 values, an old and a new value.  If these     values differ, reading the attribute returns::         new (old)      and writing will effect the ``new`` value, leaving the ``old``     unchanged.   component_size     For arrays with data redundancy (i.e. not raid0, linear, faulty,     multipath), all components must be the same size - or at least     there must a size that they all provide space for.  This is a key     part or the geometry of the array.  It is measured in sectors     and can be read from here.  Writing to this value may resize     the array if the personality supports it (raid1, raid5, raid6),     and if the component drives are large enough.   metadata_version     This indicates the format that is being used to record metadata     about the array.  It can be 0.90 (traditional format), 1.0, 1.1,     1.2 (newer format in varying locations) or ``none`` indicating that     the kernel isn't managing metadata at all.     Alternately it can be ``external:`` followed by a string which     is set by user-space.  This indicates that metadata is managed     by a user-space program.  Any device failure or other event that     requires a metadata update will cause array activity to be     suspended until the event is acknowledged.   resync_start     The point at which resync should start.  If no resync is needed,     this will be a very large number (or ``none`` since 2.6.30-rc1).  At     array creation it will default to 0, though starting the array as     ``clean`` will set it much larger.   new_dev     This file can be written but not read.  The value written should     be a block device number as major:minor.  e.g. 8:0     This will cause that device to be attached to the array, if it is     available.  It will then appear at md/dev-XXX (depending on the     name of the device) and further configuration is then possible.   safe_mode_delay     When an md array has seen no write requests for a certain period     of time, it will be marked as ``clean``.  When another write     request arrives, the array is marked as ``dirty`` before the write     commences.  This is known as ``safe_mode``.     The ``certain period`` is controlled by this file which stores the     period as a number of seconds.  The default is 200msec (0.200).     Writing a value of 0 disables safemode.   array_state     This file contains a single word which describes the current     state of the array.  In many cases, the state can be set by     writing the word for the desired state, however some states     cannot be explicitly set, and some transitions are not allowed.      Select/poll works on this file.  All changes except between     Active_idle and active (which can be frequent and are not     very interesting) are notified.  active->active_idle is     reported if the metadata is externally managed.      clear         No devices, no size, no level          Writing is equivalent to STOP_ARRAY ioctl      inactive         May have some settings, but array is not active         all IO results in error          When written, doesn't tear down array, but just stops it      suspended (not supported yet)         All IO requests will block. The array can be reconfigured.          Writing this, if accepted, will block until array is quiescent      readonly         no resync can happen.  no superblocks get written.          Write requests fail      read-auto         like readonly, but behaves like ``clean`` on a write request.      clean         no pending writes, but otherwise active.          When written to inactive array, starts without resync          If a write request arrives then         if metadata is known, mark ``dirty`` and switch to ``active``.         if not known, block and switch to write-pending          If written to an active array that has pending writes, then fails.     active         fully active: IO and resync can be happening.         When written to inactive array, starts with resync      write-pending         clean, but writes are blocked waiting for ``active`` to be written.      active-idle         like active, but no writes have been seen for a while (safe_mode_delay).   consistency_policy     This indicates how the array maintains consistency in case of unexpected     shutdown. It can be:      none       Array has no redundancy information, e.g. raid0, linear.      resync       Full resync is performed and all redundancy is regenerated when the       array is started after unclean shutdown.      bitmap       Resync assisted by a write-intent bitmap.      journal       For raid4/5/6, journal device is used to log transactions and replay       after unclean shutdown.      ppl       For raid5 only, Partial Parity Log is used to close the write hole and       eliminate resync.      The accepted values when writing to this file are ``ppl`` and ``resync``,     used to enable and disable PPL.   uuid     This indicates the UUID of the array in the following format:     xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx   bitmap_type     [RW] When read, this file will display the current and available     bitmap for this array. The currently active bitmap will be enclosed     in [] brackets. Writing an bitmap name or ID to this file will switch     control of this array to that new bitmap. Note that writing a new     bitmap for created array is forbidden.      none         No bitmap     bitmap         The default internal bitmap     llbitmap         The lockless internal bitmap If bitmap_type is not none, then additional bitmap attributes bitmap/xxx orllbitmap/xxx will be created after md device KOBJ_CHANGE event. If bitmap_type is bitmap, then the md device will also contain:   bitmap/location     This indicates where the write-intent bitmap for the array is     stored.      It can be one of ``none``, ``file`` or ``[+-]N``.     ``file`` may later be extended to ``file:/file/name``     ``[+-]N`` means that many sectors from the start of the metadata.      This is replicated on all devices.  For arrays with externally     managed metadata, the offset is from the beginning of the     device.   bitmap/chunksize     The size, in bytes, of the chunk which will be represented by a     single bit.  For RAID456, it is a portion of an individual     device. For RAID10, it is a portion of the array.  For RAID1, it     is both (they come to the same thing).   bitmap/time_base     The time, in seconds, between looking for bits in the bitmap to     be cleared. In the current implementation, a bit will be cleared     between 2 and 3 times ``time_base`` after all the covered blocks     are known to be in-sync.   bitmap/backlog     When write-mostly devices are active in a RAID1, write requests     to those devices proceed in the background - the filesystem (or     other user of the device) does not have to wait for them.     ``backlog`` sets a limit on the number of concurrent background     writes.  If there are more than this, new writes will by     synchronous.   bitmap/metadata     This can be either ``internal`` or ``external``.      ``internal``       is the default and means the metadata for the bitmap       is stored in the first 256 bytes of the allocated space and is       managed by the md module.      ``external``       means that bitmap metadata is managed externally to       the kernel (i.e. by some userspace program)   bitmap/can_clear     This is either ``true`` or ``false``.  If ``true``, then bits in the     bitmap will be cleared when the corresponding blocks are thought     to be in-sync.  If ``false``, bits will never be cleared.     This is automatically set to ``false`` if a write happens on a     degraded array, or if the array becomes degraded during a write.     When metadata is managed externally, it should be set to true     once the array becomes non-degraded, and this fact has been     recorded in the metadata. If bitmap_type is llbitmap, then the md device will also contain:   llbitmap/bits     This is read-only, show status of bitmap bits, the number of each     value.   llbitmap/metadata     This is read-only, show bitmap metadata, include chunksize, chunkshift,     chunks, offset and daemon_sleep.   llbitmap/daemon_sleep     This is read-write, time in seconds that daemon function will be     triggered to clear dirty bits.   llbitmap/barrier_idle     This is read-write, time in seconds that page barrier will be idled,     means dirty bits in the page will be cleared. As component devices are added to an md array, they appear in the ``md``directory as new directories named::       dev-XXX where ``XXX`` is a name that the kernel knows for the device, e.g. hdb1.Each directory contains:       block        a symlink to the block device in /sys/block, e.g.:: 	     /sys/block/md0/md/dev-hdb1/block -> ../../../../block/hdb/hdb1       super        A file containing an image of the superblock read from, or        written to, that device.       state	A file recording the current state of the device in the array	which can be a comma separated list of: 

Lines 1–500 of 811. Load more