On Thu, May 23 2019, Guoqing Jiang wrote:
> The sysfs nodes under bitmap are not recorded in md.4,
> add them based on md.rst and kernel source code.
>
> Cc: NeilBrown <neilb@xxxxxxxx>
> Signed-off-by: Guoqing Jiang <gqjiang@xxxxxxxx>
> ---
> Hi,
>
> Please feel free to correct the descriptions since my understanding
> could be wrong.
>
> Thanks,
> Guoqing
>
> md.4 | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 57 insertions(+)
>
> diff --git a/md.4 b/md.4
> index 3a1d6777e5b7..e81f38e40e77 100644
> --- a/md.4
> +++ b/md.4
> @@ -1101,6 +1101,63 @@ 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
> +This is only available on RAID1. when write-mostly devices are active,
> +write requests to those devices proceed in the background.
I don't think this is true. I think the file always exists, even if no
bitmap is configured.
The value stored in the file only has any effect on RAID1 when
write-mostly devices are active.
> +
> +This variable sets a limit on the number of concurrent background writes,
> +the valid values are 0 to 256, 0 means that write-behind is not allowed,
> +while any other number means it can happen. If there are more write request
requests
> +than the number, new writes will by synchronous.
> +
> +.TP
> +.B md/bitmap/can_clear
> +Write 'true' to 'bitmap/can_clear' will allow bits in the bitmap to be
> +cleared again, write 'false' means bits in the bitmap don't need to be
> +cleared.
This doesn't really explain the purpose of this attribute...
However, looking at the code doesn't make it very 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 bigger than 512.
"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 either 'internal' or 'external'. 'internal' is set by default,
> +which means the metadata for bitmap is stored in the first 256 bytes of
> +the bitmap space. 'external' means that bitmap metadata is managed externally
> +to the kernel.
I can also be "clustered".
> +
> +.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.12.3
Thanks,
NeilBrown
Attachment:
signature.asc
Description: PGP signature
