UBI plugin: collect some stats about the UBIFS

[pticon]

ChangeLog: The new "ubifs" plugin reports block state for flash memory devices with UBIFS filesystem

This plugin collects some stats about the UBIFS:

• bad physical underlying blocks (bad_peb_count)
• max erase counter value (max_ec)

Signed-off-by: Pierre Lebleu [email protected]

[rpv-tomsk]

Notes
https://unix.stackexchange.com/questions/44949/ubi-bad-block-management
https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-ubi

[pticon]

Hi @rpv-tomsk ,

Your remarks are taken into account.
The plugin is compiled only for the Linux system because it does not make sense for others.
I completed some documentation as well (README, conf file, ).

Should I drop this pull request and create an other one with an atomic commit ?

[rpv-tomsk]

Should I drop this pull request and create an other one with an atomic commit ?

I don't think you should.

You should wait for someone who is trusted contributor to merge this PR.
I'm not this one person, as I have no such permission.

Thanks for your work.

[pticon]

@octo What do you think about this ?

[dago]

LGTM

[feckert]

@dago @pticon

I was about to create a plugin for OpenWrt for the luci app-statistics. Unfortunately it's not possible to create a valid picture, because the lines are always 0. The value max_ec should 68. The value bad_peb_count is 0 but that is OK, because I have no badblock on my ubi nand.

From my point of view the used data type COUNTER is wrong. I do not want to get the rate But this is calculated with the type COUNTER. Better would be the tpye GAUGE. Or am I missing something here?
https://collectd.org/wiki/index.php/Data_source.

rrdtool info ubi/max_ec-ubi0.rrd
filename = "ubi/max_ec-ubi0.rrd"
rrd_version = "0001"
step = 30blob:https://192.168.0.53/77f43508-37b5-4ca9-897b-744f5b5692fa
last_update = 1592910344
ds[value].type = "COUNTER"
ds[value].minimal_heartbeat = 60
ds[value].min = 0.0000000000e+00
ds[value].max = NaN
ds[value].last_ds = "68"
ds[value].value = 0.0000000000e+00
ds[value].unknown_sec = 0
rra[0].cf = "AVERAGE"
rra[0].rows = 144
rra[0].pdp_per_row = 1
rra[0].xff = 1.0000000000e-01
rra[0].cdp_prep[0].value = NaN
rra[0].cdp_prep[0].unknown_datapoints = 0
rra[1].cf = "AVERAGE"
rra[1].rows = 144
rra[1].pdp_per_row = 20
rra[1].xff = 1.0000000000e-01
rra[1].cdp_prep[0].value = 0.0000000000e+00
rra[1].cdp_prep[0].unknown_datapoints = 0
rra[2].cf = "AVERAGE"
rra[2].rows = 144
rra[2].pdp_per_row = 140
rra[2].xff = 1.0000000000e-01
rra[2].cdp_prep[0].value = 0.0000000000e+00
rra[2].cdp_prep[0].unknown_datapoints = 0
rra[3].cf = "AVERAGE"
rra[3].rows = 144
rra[3].pdp_per_row = 620
rra[3].xff = 1.0000000000e-01
rra[3].cdp_prep[0].value = 0.0000000000e+00
rra[3].cdp_prep[0].unknown_datapoints = 0
rra[4].cf = "AVERAGE"
rra[4].rows = 144
rra[4].pdp_per_row = 7320
rra[4].xff = 1.0000000000e-01
rra[4].cdp_prep[0].value = 0.0000000000e+00
rra[4].cdp_prep[0].unknown_datapoints = 2249

[feckert]

@pticon @dago
I have staged a pull request to fix this and so I think that's right.