Trace Thin-Pool Blocks Back to Their Devices with thin_rmap
You will finish with a repeatable way to ask which thin-provisioned devices reference a chosen range of pool data blocks. The examples target thin_rmap 0.9.0 from thin-provisioning-tools package 0.9.0-2ubuntu5.1.
The route
Jump straight to the step you need, or tick off Done means at the end.
Allow about fifteen minutes. You need a shell, thin-provisioning-tools, and an offline copy of the pool metadata device or metadata file. The command cannot run on live metadata. This guide only reads the input, but pointing it at an active metadata device can still produce an unsafe or inconsistent result, so stop before the first query if you do not have an offline copy.
1. Check the installed command
Start with the local binary. These are ordinary, read-only commands and do not need elevated privileges:
$ command -v thin_rmap
/usr/sbin/thin_rmap
$ dpkg-query -W -f='${Package} ${Version}\n' thin-provisioning-tools
thin-provisioning-tools 0.9.0-2ubuntu5.1
$ thin_rmap --version
0.9.0
Package paths and versions differ between distributions. If the version or option output does not match, use the installed command's help as the contract for that host:
$ thin_rmap --help
Usage: thin_rmap [options] {device|file}
Options:
{-h|--help}
{-V|--version}
{--region <block range>}*
Checkpoint: you have identified the binary and confirmed that it accepts one or more --region options.
2. Obtain metadata that is not live
thin_rmap reads thin-pool metadata and builds a reverse view from pool data blocks to the thin devices that use them. Its input is the metadata device or file, not the thin data device and not a mounted filesystem.
Do not substitute a live metadata path such as a currently active pool's metadata LV. The manpage explicitly says that thin_rmap cannot be run on live metadata. Obtain an offline copy using the storage platform's supported metadata-snapshot or backup procedure, then record its path:
$ METADATA='/path/to/offline/pool-metadata'
$ test -r "$METADATA" && printf 'readable: %s\n' "$METADATA"
readable: /path/to/offline/pool-metadata
Replace the placeholder with the real file or block-device path. The test command only checks readability. If it fails, fix the path or permissions rather than reaching for sudo automatically. Elevated privileges are appropriate only when your storage procedure says the offline copy requires them, and should be limited to the read operation.
3. Choose the block range precisely
--region takes a half-open range in the form BEGIN..ONE_PAST_END. The first number is included and the second is excluded. Therefore 5..45 examines blocks 5 through 44, exactly 40 blocks.
This boundary is an easy place to lose a block. Write down the intended inclusive start and end before converting the end to one past the end. For an inclusive request covering blocks 1000 through 1031, the command range is 1000..1032, not 1000..1031.
At least one region is required, and multiple regions may be supplied. Keep the ranges explicit so a later review can see exactly which parts of the data device were investigated.
4. Produce the reverse map
Run the command against the offline metadata copy. This is the first operation that reads your supplied metadata, so check the path and range once more before pressing Enter:
$ thin_rmap --region 5..45 "$METADATA"
<reverse mapping for data blocks 5 through 44 is printed here>
The reverse mapping is written to standard output. Its contents depend on the metadata, so do not treat the placeholder line above as literal output or infer that every block must have a mapping. Capture the result when you need an audit trail:
$ thin_rmap --region 5..45 "$METADATA" > thin-rmap-5-45.txt
$ printf 'exit status: %s\n' "$?"
exit status: 0
$ less thin-rmap-5-45.txt
Status 0 means the query succeeded. The documented error status is 1. A non-zero result is not a finding about the thin devices: it means the query itself failed, so preserve the diagnostic and check the input path, range syntax and metadata state before interpreting anything.
Checkpoint: the saved report names its range, and you recorded the command's exit status separately from the mapping text.
5. Query more than one region
Repeat --region when you need separate ranges in one invocation. For example, this asks for the two half-open intervals 5 through 44 and 1000 through 1031:
$ thin_rmap \
--region 5..45 \
--region 1000..1032 \
"$METADATA" > thin-rmap-selected-regions.txt
$ status=$?
$ printf 'exit status: %s\n' "$status"
exit status: 0
Keep the output associated with the exact command that generated it. If you need unambiguous separation for downstream processing, run one region per file instead of assuming that the tool's human-readable output is a stable interchange format. The thin_rmap manpage documents the query and exit status, but does not promise a machine-readable schema for the printed reverse map.
6. Handle failures without changing storage
First rerun thin_rmap --help and verify that each range has both numbers, uses two dots, and has a one-past-the-end value greater than its start. Then confirm that the input is the offline metadata copy, not the live pool path.
Do not use thin_rmap as a repair command. It has no repair or write option in this installed interface, and changing a live thin pool to make a query work would be a service-disrupting storage operation. If the offline metadata is damaged, preserve the original and investigate with the appropriate thin-provisioning checks or recovery procedure. Never overwrite the only copy while troubleshooting.
There is no undo step for a successful query: thin_rmap does not change the metadata. Remove or retain the report according to your normal handling rules. If the report contains sensitive device layout information, protect it like other storage diagnostics.
Done means
- You confirmed the installed thin_rmap and thin-provisioning-tools versions.
- You used an offline metadata device or file, never live pool metadata.
- You converted the requested inclusive block end to a one-past-the-end range.
- You supplied at least one explicit
--regionand captured the exit status. - You treated status 0 as a successful query and status 1 as a command error.
- You kept the generated report tied to its exact metadata path and ranges.