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: mdadm