Replace Unsupported lvmsar Checks with dmstats

You will finish with a safe way to check device-mapper statistics on an LVM2 host, and you will know when a statistics region must be created before reporting anything. The installed lvmsar manual is explicit: lvmsar is not supported under LVM2. The supported direction is the device-mapper statistics facility, managed by dmstats.

Allow about fifteen minutes for a read-only check, or longer if you need to create and remove a region. The examples use LVM tools 2.03.16(2), installed here from Ubuntu package lvm2 2.03.16-3ubuntu3.2. You need the lvm2 package and a device-mapper device. Reading statistics may require root on your host. Creating, clearing and deleting regions changes kernel-managed monitoring state, so use an approved maintenance window and record the device you select.

1. Confirm what is installed

Start with read-only commands. They do not need elevated privileges, although the command may still be unable to contact the device-mapper driver in a restricted shell:

$ command -v lvmsar
/usr/sbin/lvmsar
$ lvm version
  LVM version:     2.03.16(2) (2022-05-18)
$ dmstats --help

The important result is not an old lvmsar output format. This installation ships an lvmsar wrapper that reports that there is no lvmsar command in LVM2 and tells you to use dmstats. Do not build automation around that warning or treat a zero-length report as valid monitoring data.

2. Inspect existing statistics regions

With device-mapper access available, list regions that already exist:

$ sudo dmstats list
$ sudo dmstats report --count 1

list shows the statistics objects known to dmstats. report --count 1 requests one report and then exits. The output depends on the device-mapper devices and regions on your host, so do not compare its columns with a remembered lvmsar transcript. If no device argument is given, dmstats operates on all present device-mapper devices for read operations.

On a host without access to /dev/mapper/control, the command fails before it can collect data. The failure is an environment or permission problem, not evidence that the LVM volume has no activity. Check the service context, device-mapper availability and the exact error before adding more options:

$ sudo dmstats list
# Expected shape on a restricted host:
# /dev/mapper/control: open failed: Permission denied
# Command failed.

Do not use sudo blindly in a monitoring script. Decide whether the script should run as root, whether a narrowly scoped privilege rule is appropriate, or whether the host intentionally has no device-mapper access.

3. Create a region only when inspection needs one

Existing regions can be reported immediately. If the list is empty and you need statistics for a specific device, creating a region is the state-changing step. First identify the exact device-mapper name without guessing:

$ ls -l /dev/mapper
$ sudo dmsetup ls --tree

Replace DEVICE_NAME below with an exact name from your host. The following creates a region covering the device, with one area, and tags it with a distinctive program ID. The command requires elevated privileges on most systems:

$ sudo dmstats create DEVICE_NAME --areas 1 --programid lvmsar-replacement
region_id: 0

The region ID is assigned by the kernel and may not be 0. Keep the actual ID from your output. Creation starts collecting counters for that region; it does not reconstruct historical activity. The default program ID for dmstats-created regions is dmstats, but using an explicit value makes later selection less ambiguous.

4. Collect a bounded report

Ask for one report while selecting only the regions created for this exercise:

$ sudo dmstats report --programid lvmsar-replacement --count 1
$ sudo dmstats list --programid lvmsar-replacement

For a short sample, use an interval and a finite count:

$ sudo dmstats report DEVICE_NAME --interval 5 --count 3 --programid lvmsar-replacement

This requests three reports five seconds apart. A command with --interval and no --count continues until interrupted, so always set a count in a test or scheduled probe unless continuous output is deliberate. Use --units, --noheadings or --separator only after checking the local help for the output format your parser expects.

5. Remove temporary monitoring state

When you have finished, remove the region you created. This is another elevated, state-changing command, and it releases the counters and resources for that region:

$ sudo dmstats delete DEVICE_NAME --programid lvmsar-replacement
$ sudo dmstats list --programid lvmsar-replacement

The final list should contain no region with that program ID. If you recorded a region ID and need a narrower removal, use --regionid REGION_ID instead. Check the command's output before confirming a deletion. Deleting a region cannot restore its counters, so export or record any measurements you need first.

If this was a permanent monitoring setup rather than a test, do not delete the region as part of a routine script. Document its device, program ID and owner, then manage its lifetime through the same operational process that created it. dmstats clear resets counters and is also destructive to the measurement history; it is not an alternative to reporting.

6. Diagnose the common traps

• lvmsar prints a replacement warning: this is expected for LVM2. Switch the workflow to dmstats rather than searching for undocumented lvmsar flags.
• There are no rows: distinguish an empty region list from a failure to open the device-mapper control node. Run the command with its diagnostic output visible.
• A report never ends: add a finite --count. An interval without a count is intentionally repeating.
• You cannot delete what you created: check the exact device name, program ID and region ID from the create output. Do not broaden the command to all devices.