| Message ID | 20200608084513.115671-1-yangerkun@huawei.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | introduce interface to list all badblocks | expand |
Hi, Sorry for not send to Mike. Can you consider to apply this patchset? Thanks, Kun. 在 2020/6/8 16:45, yangerkun 写道: > We can add/remove/query the badblocks, but no interface to list all > badblocks when we want to know the badblocks we ever set still > available. Add message listbadblocks to do this. > > To list all bad blocks in the bad block list, run the following > message command: > > $ sudo dmsetup message dust1 0 listbadblocks > > The following message will appear, listing one bad block number per > line (using an example device with blocks 1 and 2 in the bad block > list): > > device-mapper: dust: dust_list_badblocks: badblocks list below: > device-mapper: dust: bad block: 1 > device-mapper: dust: bad block: 2 > device-mapper: dust: dust_list_badblocks: badblocks list end. > > > yangerkun (2): > dm dust: add interface to list all badblocks > dm dust: introduce listbadblocks in the rst > > .../admin-guide/device-mapper/dm-dust.rst | 18 ++++++++++++++++ > drivers/md/dm-dust.c | 21 +++++++++++++++++++ > 2 files changed, 39 insertions(+) > -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
On Mon, Jun 08, 2020 at 04:45:11PM +0800, yangerkun wrote: > $ sudo dmsetup message dust1 0 listbadblocks > The following message will appear, listing one bad block number per Did you consider returning the data directly to the caller so it can be accessed directly? (e.g. like @stats_list handled in dm-stats.c) Alasdair -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
On Mon, Jun 15, 2020 at 06:03:31PM +0100, Alasdair G Kergon wrote: > On Mon, Jun 08, 2020 at 04:45:11PM +0800, yangerkun wrote: > > $ sudo dmsetup message dust1 0 listbadblocks > > The following message will appear, listing one bad block number per > > Did you consider returning the data directly to the caller so it > can be accessed directly? > > (e.g. like @stats_list handled in dm-stats.c) Having this returned in the message response would certainly be more natural and would simplify parsing the data: sending it to the log seems like it would allow log lines from distinct devices to become interleaved when the lists are long and the message is sent to two or more devices near simultaneously. Without something to identify the devices in each message you can't distinguish them. Even with large numbers of bad blocks userspace libdevmapper will automatically handle re-trying with a larger buffer if the list is too big for the default. We use (sometimes very large) message replies heavily in libdm-stats. device-mapper.h provides the DMEMIT macro to output message replies. See dm_stats_print() or various target status() functions for examples. Regards, Bryn. -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
在 2020/6/16 20:28, Bryn M. Reeves 写道: > On Mon, Jun 15, 2020 at 06:03:31PM +0100, Alasdair G Kergon wrote: >> On Mon, Jun 08, 2020 at 04:45:11PM +0800, yangerkun wrote: >>> $ sudo dmsetup message dust1 0 listbadblocks >>> The following message will appear, listing one bad block number per >> >> Did you consider returning the data directly to the caller so it >> can be accessed directly? >> >> (e.g. like @stats_list handled in dm-stats.c) > > Having this returned in the message response would certainly be more > natural and would simplify parsing the data: sending it to the log seems > like it would allow log lines from distinct devices to become > interleaved when the lists are long and the message is sent to two or > more devices near simultaneously. Without something to identify the > devices in each message you can't distinguish them. > > Even with large numbers of bad blocks userspace libdevmapper will > automatically handle re-trying with a larger buffer if the list is too > big for the default. > > We use (sometimes very large) message replies heavily in libdm-stats. > > device-mapper.h provides the DMEMIT macro to output message replies. > See dm_stats_print() or various target status() functions for > examples. > > Regards, > Bryn. > Hi, Thanks for your reply! I will read this code and consider to realize it! Thanks, Kun. > > . > -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
We can add/remove/query the badblocks, but no interface to list all badblocks when we want to know the badblocks we ever set still available. Add message listbadblocks to do this. To list all bad blocks in the bad block list, run the following message command: $ sudo dmsetup message dust1 0 listbadblocks The following message will appear, listing one bad block number per line (using an example device with blocks 1 and 2 in the bad block list): device-mapper: dust: dust_list_badblocks: badblocks list below: device-mapper: dust: bad block: 1 device-mapper: dust: bad block: 2 device-mapper: dust: dust_list_badblocks: badblocks list end. yangerkun (2): dm dust: add interface to list all badblocks dm dust: introduce listbadblocks in the rst .../admin-guide/device-mapper/dm-dust.rst | 18 ++++++++++++++++ drivers/md/dm-dust.c | 21 +++++++++++++++++++ 2 files changed, 39 insertions(+)