Compare Thin-Volume Mappings Safely with thin_delta

Two snapshots have drifted apart and nobody can say by how much until thin_delta compares their block mappings and prints the difference. Allow about ten minutes if you already have a metadata device or file and know the two thin-volume identifiers, and check that the comparison used the intended IDs and a stable metadata source before you trust the answer. The installed command is thin-provisioning-tools 0.9.0.

This is a read-only inspection guide: the command does not activate a thin volume, create a snapshot or repair metadata. You normally need no elevated privileges when the metadata input is readable by your account. Use sudo only when access to the selected device or file requires it, and confirm the path before running anything as root.

1. Check the installed command

Confirm which binary will run and record its version:

$ command -v thin_delta
/usr/sbin/thin_delta
$ thin_delta --version
0.9.0

The path can differ between distributions. The useful checks are that the command exists and that its version is the one whose behaviour you are documenting. The local manual describes the input as a device or file containing thin metadata.

Checkpoint: ask for the local option list if you are working on another host:

$ thin_delta --help
Usage: thin_delta [options] <device or file>

2. Identify the two thin IDs

thin_delta compares identifiers, not human-readable volume names. Set two decimal IDs supplied by your thin-provisioning inventory. In the examples below, 101 and 102 are placeholders, not values to copy blindly.

$ THIN_ONE=101
$ THIN_TWO=102
$ printf 'first=%s second=%s\n' "$THIN_ONE" "$THIN_TWO"
first=101 second=102

The installed manual calls the options --thin1 and --thin2. It also documents --snap1 and --snap2 as aliases. Use the longer names in a script because they make the two roles easier to review. Do not assume that adjacent IDs belong to related snapshots.

Checkpoint: write down which real volume each ID represents before comparing them. If the inventory does not give you the IDs, stop and obtain that mapping from the system that manages the pool. A plausible-looking comparison of the wrong IDs is still a wrong result.

3. Compare a stable metadata input

For an offline metadata device or file that is not being changed, pass the path and both IDs:

$ thin_delta \
    --thin1 "$THIN_ONE" \
    --thin2 "$THIN_TWO" \
    /path/to/metadata-input

Replace /path/to/metadata-input with the actual metadata device or file. Keep the input as an explicit final argument. The command prints the differences in the mappings to standard output; the exact lines depend on the metadata and the installed tool version, so do not use a made-up output sample as a success test.

Capture the exit status immediately after the command:

$ status=$?
$ printf 'thin_delta exit status: %s\n' "$status"
thin_delta exit status: 0

Status 0 means the command completed successfully. It does not prove that the selected IDs describe the volumes you intended, so retain the inventory check from step 2.

4. Read live metadata through a metadata snapshot

The manual refuses live metadata unless you use --metadata-snap. A metadata snapshot is a separate pool operation. Obtain one using the procedure appropriate to your thin-provisioning setup, and record the snapshot block number it reports. This guide does not invent a snapshot-creation command because the manpage only documents how thin_delta consumes the snapshot.

When the metadata snapshot block number is BLOCK_NR, run:

$ thin_delta \
    --metadata-snap BLOCK_NR \
    --thin1 "$THIN_ONE" \
    --thin2 "$THIN_TWO" \
    /path/to/live-metadata-device

The value after --metadata-snap is a block number, not a file name and not the thin ID. The metadata device or file remains the final positional argument. If your local help shows the short form, -m BLOCK_NR is equivalent on this installed 0.9.0 command.

5. Request more mapping detail

Add --verbose when the normal comparison does not provide enough mapping detail for your investigation:

$ thin_delta \
    --verbose \
    --thin1 "$THIN_ONE" \
    --thin2 "$THIN_TWO" \
    /path/to/metadata-input \
    > thin-delta.txt
$ test -s thin-delta.txt
$ printf 'comparison output was written\n'
comparison output was written

Redirecting output creates or truncates thin-delta.txt. If that file already contains evidence, choose a new name or make a backup first. To discard this newly created report after checking it, use rm -- thin-delta.txt only after confirming the path; deletion is irreversible. The metadata device and thin volumes are not changed by this redirection.

6. Diagnose the common failures

$ ls -l -- /path/to/metadata-input
$ test -r /path/to/metadata-input && printf '%s\n' 'metadata input is readable'

• "Couldn't stat path" usually means the positional argument is wrong, not that metadata is damaged. Run the readability check above before assuming anything worse.
• Check you picked the metadata device, not the data device. If it is readable only by root, rerun the complete command with sudo after reviewing every argument.
• Do not reach for repair tools on a path error. Comparing wrongly and repairing wrongly are two different mistakes; fixing the path solves the first without risking the second.
• A clean run with a meaningless answer usually means the wrong IDs or a moving target. Check the thin IDs, the metadata snapshot block number, and whether either volume changed during the read. A snapshot does not make a changing thin volume safe to interpret; the requirement is that the examined thins stay inactive and unchanged.

For a command-line diagnostic rather than a comparison, use thin_delta --help or thin_delta --version. The command has no option in its installed manual for modifying mappings, activating volumes or undoing a comparison, so recovery means correcting the input and rerunning the read-only check, not reversing anything thin_delta did.