Guess the metadata size for a dm-cache setup and you either waste space or box yourself in later; cache_metadata_size does the arithmetic instead. It gives a reproducible estimate in 512-byte sectors, calculated from your fast device, not the slow one. This guide uses thin-provisioning-tools 0.9.0-2ubuntu5.1, whose command reports version 0.9.0.
Allow about ten minutes. You need a shell and the thin-provisioning-tools package. Everything here is read-only: it calculates a size and does not create, resize or attach any block device, and no root access is normally needed.
Confirm which executable your shell will actually run and record the package version, so you are not silently using a different build when a host has more than one copy installed:
$ command -v cache_metadata_size
/usr/sbin/cache_metadata_size
$ dpkg-query -W -f='${Package} ${Version}\n' thin-provisioning-tools
thin-provisioning-tools 0.9.0-2ubuntu5.1
$ cache_metadata_size --version
0.9.0Checkpoint: If the command is missing, stop here and install the package through your normal system-management process. Do not substitute a similarly named metadata utility: this one estimates dm-cache metadata, and its inputs describe the fast device.
The command takes either a known block count, or a block size paired with the fast device size. Each option counts a different unit:
--nr-blocks is the number of cache blocks.--block-size is the cache block size in 512-byte sectors.--device-size is the total fast-device size in 512-byte sectors.--max-hint-width changes the per-block hint width in bytes; the installed manual says current policies default to 4 bytes.Already know your block count? Use --nr-blocks. Know the fast device capacity and block size instead? Supply both --block-size and --device-size together. Never pass the size of the whole cached device: the command's own help calls these values properties of the fast device, the SSD, not the array behind it.
For a configuration with 10,240 cache blocks:
$ cache_metadata_size --nr-blocks 10240
8752 sectorsThe result is the estimated metadata-device size in sectors. One sector here is 512 bytes, so 8,752 sectors is 4,481,024 bytes, roughly 4.27 MiB. Treat that as the tool's estimate when you provision storage; do not quietly round it down.
The block count must be a natural number the installed command accepts. Zero is accepted by this version and still produces a metadata overhead estimate, though it is not a useful cache configuration:
$ cache_metadata_size --nr-blocks 0
8192 sectorsCheckpoint: Compare the block count against the cache configuration you actually intend to build. A block count derived from the wrong device size gives a plausible-looking but irrelevant answer.
Say the fast device is 1,024,000 sectors and each cache block is 128 sectors. Supply both:
$ cache_metadata_size --block-size 128 --device-size 1024000
8629 sectors1,024,000 sectors is 524,288,000 bytes; 128 sectors is a 65,536-byte cache block. This is still a metadata estimate, not a request to allocate the fast device. Leave either value out and this version refuses the calculation outright:
$ cache_metadata_size --block-size 128
If you specify --block-size you must also give --device-size.Use the exact sector counts from the storage layout you are planning. Do not convert a decimal manufacturer capacity to sectors by guessing, and do not reach for the slow device's size just because it is easier to find.
Cache policies keep a per-block hint. The manual documents a 4-byte default and lets you pass another width with --max-hint-width. Include it only when your policy or deployment actually requires it:
$ cache_metadata_size --nr-blocks 10240 --max-hint-width 8
8832 sectorsThat result comes out larger than the default-width estimate for the same block count. Keep the hint width consistent with the real cache configuration; changing it in the estimate without changing the policy just makes the number harder to audit later.
Checkpoint: Save the command, every numeric input and the output alongside your storage change record. The output line alone does not say which inputs produced it.
cache_metadata_size creates nothing and modifies nothing. The next step, partitioning, creating a logical volume, assembling a device-mapper cache, is separate, and it can be destructive or disrupt a live service. Before doing any of that, verify the target path with a read-only command such as lsblk, take the backup your storage procedure requires, and schedule a maintenance window if the devices are live.
Do not use shell redirection to overwrite a configuration file as part of this estimate; keep the output in your change record first. Wrong inputs? Just rerun with corrected values, there is nothing to undo, since the estimator changes no system state.
A successful exit status only says the calculation completed. It does not validate your device-mapper table, your free space, alignment, filesystem workload or the suitability of a cache policy. Those checks belong to the later design and deployment work.
--nr-blocks is a count, not a sector size.--max-hint-width.--block-size without --device-size. Add the missing option rather than guessing a default; the command requires both and infers neither.