From e53cb968691d9e40d83caf5570da3bb7b83c64e1 Mon Sep 17 00:00:00 2001

From: Guoqing Jiang <gqjiang@suse.com>

Date: Fri, 31 May 2019 10:10:00 +0800

Subject: [RHEL7.8 PATCH V2 38/47] mdadm/md.4: add the descriptions for bitmap

 sysfs nodes

The sysfs nodes under bitmap are not recorded in md.4,

add them based on md.rst and kernel source code.

Cc: NeilBrown <neilb@suse.com>

Signed-off-by: Guoqing Jiang <gqjiang@suse.com>

Signed-off-by: Jes Sorensen <jsorensen@fb.com>

---

 md.4 | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 1 file changed, 69 insertions(+)

diff --git a/md.4 b/md.4

index 3a1d677..e86707a 100644

--- a/md.4

+++ b/md.4

@@ -1101,6 +1101,75 @@ stripe that requires some "prereading".  For fairness this defaults to

 maximizes sequential-write throughput at the cost of fairness to threads

 doing small or random writes.

+.TP

+.B md/bitmap/backlog

+The value stored in the file only has any effect on RAID1 when write-mostly

+devices are active, and write requests to those devices are proceed in the

+background.

+

+This variable sets a limit on the number of concurrent background writes,

+the valid values are 0 to 16383, 0 means that write-behind is not allowed,

+while any other number means it can happen.  If there are more write requests

+than the number, new writes will by synchronous.

+

+.TP

+.B md/bitmap/can_clear

+This is for externally managed bitmaps, where the kernel writes the bitmap

+itself, but metadata describing the bitmap is managed by mdmon or similar.

+

+When the array is degraded, bits mustn't be cleared. When the array becomes

+optimal again, bit can be cleared, but first the metadata needs to record

+the current event count. So md sets this to 'false' and notifies mdmon,

+then mdmon updates the metadata and writes 'true'.

+

+There is no code in mdmon to actually do this, so maybe it doesn't even

+work.

+

+.TP

+.B md/bitmap/chunksize

+The bitmap chunksize can only be changed when no bitmap is active, and

+the value should be power of 2 and at least 512.

+

+.TP

+.B md/bitmap/location

+This indicates where the write-intent bitmap for the array is stored.

+It can be "none" or "file" or a signed offset from the array metadata

+- measured in sectors. You cannot set a file by writing here - that can

+only be done with the SET_BITMAP_FILE ioctl.

+

+Write 'none' to 'bitmap/location' will clear bitmap, and the previous

+location value must be write to it to restore bitmap.

+

+.TP

+.B md/bitmap/max_backlog_used

+This keeps track of the maximum number of concurrent write-behind requests

+for an md array, writing any value to this file will clear it.

+

+.TP

+.B md/bitmap/metadata

+This can be 'internal' or 'clustered' or 'external'. 'internal' is set

+by default, which means the metadata for bitmap is stored in the first 256

+bytes of the bitmap space. 'clustered' means separate bitmap metadata are

+used for each cluster node. 'external' means that bitmap metadata is managed

+externally to the kernel.

+

+.TP

+.B md/bitmap/space

+This shows the space (in sectors) which is available at md/bitmap/location,

+and allows the kernel to know when it is safe to resize the bitmap to match

+a resized array. It should big enough to contain the total bytes in the bitmap.

+

+For 1.0 metadata, assume we can use up to the superblock if before, else

+to 4K beyond superblock. For other metadata versions, assume no change is

+possible.

+

+.TP

+.B md/bitmap/time_base

+This shows the time (in seconds) between disk flushes, and is used to looking

+for bits in the bitmap to be cleared.

+

+The default value is 5 seconds, and it should be an unsigned long value.

+

 .SS KERNEL PARAMETERS

 The md driver recognised several different kernel parameters.

-- 

2.7.5