Validate Era Metadata Safely with era_check

Run era_check on device-mapper era metadata and you get a pass or fail, provided the era target is not still using it. You will finish with a repeatable check for metadata on a block device or file, while avoiding the most dangerous mistake: checking metadata that is live. The examples match thin-provisioning-tools 0.9.0-2ubuntu5.1, whose installed era_check reports version 0.9.0.

Allow about ten minutes for a read-only check, plus whatever maintenance time your storage stack needs to make the metadata inactive. You need the metadata device or file, a shell, and read access to it. You do not need sudo unless the path permissions or your storage management procedure require it.

1. Confirm the installed command

Check the binary and package before relying on examples from another host. These are ordinary, read-only commands:

$ command -v era_check
/usr/sbin/era_check
$ dpkg-query -W -f='${Package} ${Version}\n' thin-provisioning-tools
thin-provisioning-tools 0.9.0-2ubuntu5.1
$ era_check --version
0.9.0

The synopsis is era_check [options] {device|file}. It takes one required operand: a device node, or a regular file containing era metadata. Do not give it a filesystem mount point unless that mount point is itself the metadata path you mean to inspect.

Checkpoint: you have identified the exact metadata path and confirmed which installed program will read it.

2. Stop before checking live metadata

era_check cannot be run on live metadata. The metadata device must not be in active use by the device-mapper era target while the check runs. This is a safety boundary, not an optional performance hint.

Warning: do not guess that a quiet system is safe. Use the normal maintenance procedure for your deployment to stop or deactivate the era target, and confirm that the metadata path is no longer in use before you continue. That procedure depends on the volume manager and service layout on the host, so this guide does not invent a universal stop command.

Deactivating a target can interrupt storage-backed services. Schedule a maintenance window, record the service changes you make, and keep their normal restart or rollback procedure to hand. era_check itself is a validator. It has no undo command and does not repair metadata.

Checkpoint: the target is inactive, the path is still readable, and you know how to restore the storage service after the check.

3. Run a full metadata check

Pass the inactive metadata device or file as the final argument. The example uses the logical-volume path shown in the manual:

$ era_check /dev/vg/metadata
$ printf 'exit status: %s\n' "$?"
exit status: 0

Read the result from the exit status:

A successful run may print nothing useful, so rely on the status rather than an assumed success message. If the metadata path is protected, rerun the same check through your approved elevated-access procedure, for example sudo era_check /dev/vg/metadata. Elevation changes who can read the path. It does not make live metadata safe to inspect.

Warning: do not redirect output over the metadata path or pass a path you have not checked. The command reads the device or file you give it, but storage mistakes are still easy when you copy a logical-volume name.

4. Use the superblock-only check for a narrow probe

Use --super-block-only when you only need to know the era superblock is present:

$ era_check --super-block-only /dev/vg/metadata
$ printf 'exit status: %s\n' "$?"
exit status: 0

This is narrower than the default check. A successful superblock-only result does not show that the rest of the metadata passes full validation. Treat it as an early probe or a separate diagnostic, then run the full check when the target is inactive and you need confidence in all of the metadata.

5. Make scripts quiet without losing the result

-q and --quiet suppress output messages and leave the exit code as the result. Capture that code immediately:

$ if era_check --quiet /dev/vg/metadata; then
>     echo 'era metadata check passed'
> else
>     status=$?
>     printf 'era metadata check failed, exit status: %s\n' "$status" >&2
> fi
era metadata check passed

Do not run another command before reading $?, because the shell replaces it after every command. In automation, treat any non-zero status as a failed check and leave the metadata inactive until an operator has investigated. Quiet mode suits a monitoring or maintenance wrapper, but it never turns a failed check into a pass.

6. Diagnose a failed check without changing data

First confirm the operand and permissions, then confirm the era target is still inactive. A harmless negative test shows the contract without touching a real metadata device:

$ era_check /dev/null
/dev/null: Not a block device or regular file
$ printf 'exit status: %s\n' "$?"
exit status: 1

The exact diagnostic for a real failure depends on the path and its contents. A non-zero result can mean any of these:

Check the path with your normal read-only inspection tools and verify the storage state before trying again.

Warning: do not overwrite, truncate, restore or otherwise alter the metadata just to make the check pass.

Recovery: if you checked only the superblock, repeat the full command once the underlying issue is resolved. If the full check fails, preserve the original metadata and follow your documented recovery plan for the thin-provisioning stack. Recovery is not a blind rerun. The failed result is evidence to investigate.

Done means