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.

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.

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.

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:

• Status 0 means the check succeeded.
• Status 1 means an error occurred.

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.

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:

• Wrong operand. It is not a suitable device or file.
• Unreadable path. The path cannot be read.
• Bad metadata. The metadata is invalid.
• Metadata in use. It is being used in a way the tool cannot safely check.

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