Application tagging — telling Ceph who owns a pool

Foundation⏱ ~14 minceph

What you'll learn

Set application tags correctly for each service
Explain what the tag affects beyond the health warning
Diagnose problems caused by missing or wrong tags
Use tags to document pool ownership

Prerequisites

None — start here.

Verified against Ceph Tentacle 20.2.x · Ceph Squid 19.2.x (supported previous) · cephadm matches the verified Ceph release · podman 4.x · csi-rbd and csi-cephfs current · RBD / CephFS / RGW current (matches Ceph release) · Linux kernel 5.15+ (5.10 minimum) · Ubuntu 24.04 LTS (Ceph host baseline) · Debian 12 (Bookworm) (Ceph host baseline) · Rocky Linux / RHEL / AlmaLinux 9.x (Ceph host baseline) · Proxmox VE 9.x (cross-course integration) · Kubernetes 1.31+ (cross-course integration) · 2026-08-18

Why this matters in production

POOL_APP_NOT_ENABLED is one of the most frequently muted health warnings in Ceph, and muting it is how clusters arrive at pools nobody can identify.

Setting the tag

ceph osd pool application enable rbd-vms rbd
ceph osd pool application enable cephfs_data cephfs
ceph osd pool application enable rgw-data rgw
ceph osd pool application get rbd-vms
ceph osd pool ls detail | grep application

The three standard values are rbd, cephfs, and rgw. Custom values are allowed for pools used directly through librados:

ceph osd pool application enable app-state my-application

What the tag affects

Beyond silencing the warning:

rbd refuses to operate on untagged pools. rbd create against a pool without the rbd tag fails.
CephFS and RGW expect their pools tagged, and tooling uses the tag to identify them.
The dashboard groups pools by application.
It documents intent, which on a cluster with fifteen pools and four years of history is the single most useful property.

Never mute POOL_APP_NOT_ENABLED — fix it

POOL=rbd-vms
APP=app
ceph health mute POOL_APP_NOT_ENABLED      # do not do this
ceph osd pool application enable ${POOL} ${APP}    # do this

The warning takes one command to resolve per pool. Muting it takes one command and permanently removes the only signal that a pool exists whose purpose nobody recorded.

The failure this creates is specific and common: two years later someone finds a 2 TB pool with no tag, no documentation, and no way to determine whether deleting it destroys something important. The identification work then costs hours and the answer is often uncertain.

If a pool genuinely has no application because it is unused, that is a reason to delete it, not to mute the warning about it.

Identifying an untagged pool

If you inherit one:

# POOL is the untagged pool, from `ceph osd pool ls`; substitute your own:
POOL=rbd-vms

rados -p "$POOL" ls | head -20

Object naming identifies the owner:

Pattern	Owner
`rbd_data.<hex>.<seq>`, `rbd_header.<hex>`	RBD
`<hex>.00000000` with an inode-shaped prefix	CephFS data
`<marker>_<key>`, `.dir.<marker>`	RGW
anything else	direct librados or unknown

POOL=rbd-vms
ceph osd pool stats ${POOL}       # is it receiving I/O?
ceph df detail                   # how large is it?

Why the tag is metadata Ceph acts on rather than a label

Application tags are stored per pool in the osdmap and can carry key-value metadata beyond the bare name:

ceph osd pool application set rbd-vms rbd owner platform-team
ceph osd pool application get rbd-vms

RBD uses this to record image-related pool metadata. CephFS uses tags to associate data and metadata pools with a filesystem, which is why ceph fs new sets them automatically.

The practical consequence is that a wrong tag is worse than no tag. A pool tagged cephfs that actually holds RBD images will be treated as part of a filesystem by tooling that enumerates by tag, and operations that assume the tag is truthful can behave unexpectedly.

So the tag should be set once, correctly, at pool creation — and the custom key-value form is a good place to record the owning team, which survives in the cluster rather than only in a document.

The habit

Add it to pool creation:

NAME=acme
PGS=pgs
RULE=replicated_rule
APP=app
TEAM=team
ceph osd pool create ${NAME} ${PGS} ${PGS} replicated ${RULE}
ceph osd pool set ${NAME} size 3
ceph osd pool set ${NAME} min_size 2
ceph osd pool application enable ${NAME} ${APP}
ceph osd pool application set ${NAME} ${APP} owner ${TEAM}

Four commands, one of which is the tag. Nobody mutes a warning that never fires.

Quiz

Knowledge check · 4 questions

Q1. What happens if you attempt rbd create against a pool with no application tag?

It succeeds, and the rbd tag is set on the pool automatically It succeeds after printing a warning about the missing tag It succeeds, but the image stays invisible to rbd ls afterwards It fails, because rbd refuses to operate on pools not tagged rbd
Q2. A wrong application tag is less harmful than no tag at all.

True False
Q3. An inherited cluster has POOL_APP_NOT_ENABLED muted and three untagged pools. Identify them.

Three untagged pools of 40 GB, 900 GB, and 4 TB. The warning has been muted for eighteen months. No documentation exists. ceph osd pool stats shows the 4 TB pool receiving steady I/O, the 900 GB pool receiving occasional I/O, and the 40 GB pool receiving none. The team wants to tag what is in use and reclaim what is not.
Q4. Explain why POOL_APP_NOT_ENABLED should be fixed rather than muted.

Passing score: 75%. Answers are checked in this browser.

Production discipline

Put ceph osd pool application enable in the pool creation procedure so the warning never fires, and use the key-value form to record the owning team in the cluster rather than only in a document. Never mute POOL_APP_NOT_ENABLED — it takes one command to resolve and muting it is how clusters end up with pools nobody can identify. And set the tag correctly the first time, since a wrong tag causes silent misidentification where a missing one at least asks to be fixed.

Cross-course references

Ceph: Part XVII lesson on pool purpose for the wider design.
Ceph: Part LIII (Cluster Health) for handling warnings generally.
Ceph: Part XLII (CephFS Operations) for filesystem pool tags.