mdadm bitmap erstellen

Bei RAIDs kommt es ab und an einmal vor, dass Festplatten aus dem RAID geworfen werden. Eine wieder hinzugefügte Festplatte muss dann wieder gesynct (resharpt) werden. In meinem Beispiel von 4x2TB Festplatten in einem RAID 5, dauert dass ca. 4 Stunden. Um die Wahrscheinlichkeit das während des resharpen eine weiter Festplatte ausfällt, das den Totaluferlust der Daten bedeuten würde, zu minimieren. Ist es sinnvoll auf kosten der Schreibperformance ein bitmap zu erstellen.

mdadm --grow --bitmap=internal /dev/md0

Alternativ kann man das bitmap auch auf eine separate Festplatte schreiben, dies erhört die schreib Performance des RAIDs.

mdadm --grow --bitmap=/mnt/bitmap-md0.bin /dev/md0

Um die bitmaps wieder auszuschalten muss man none angeben:

mdadm --grow --bitmap=none /dev/md0

  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.

Quelle: kernel.org/doc/md.txt

Tags: