Metadata
^^^^^^^^
-We have three 'sections' of metadata: 'user', 'bucket', and 'bucket.instance'.
-You can use the following commands to inspect metadata entries: ::
+RGW stores multiple types of metadata. The list of types can be shown
+with the below command. The types as of 2025 April are shown below:
- $ radosgw-admin metadata list
- $ radosgw-admin metadata list bucket
- $ radosgw-admin metadata list bucket.instance
- $ radosgw-admin metadata list user
+.. prompt:: bash #
- $ radosgw-admin metadata get bucket:<bucket>
- $ radosgw-admin metadata get bucket.instance:<bucket>:<bucket_id>
- $ radosgw-admin metadata get user:<user> # get or set
+ radosgw-admin metadata list
+
+::
+
+ [
+ "account",
+ "bucket",
+ "bucket.instance",
+ "group",
+ "otp",
+ "roles",
+ "topic",
+ "user"
+ ]
+
+Use commands of the following forms to inspect metadata entries:
+
+.. prompt:: bash #
+
+ radosgw-admin metadata list
+ radosgw-admin metadata list bucket
+ radosgw-admin metadata list bucket.instance
+ radosgw-admin metadata list user
+ radosgw-admin metadata get bucket:<bucket>
+ radosgw-admin metadata get bucket.instance:<bucket>:<bucket_id>
+ radosgw-admin metadata get user:<user> # get or set
Some variables have been used in above commands, they are:
An RGW object may comprise multiple RADOS objects, the first of which
is the ``HEAD`` that contains metadata including manifest, ACLs, content type,
ETag, and user-defined metadata. The metadata is stored in xattrs.
-The ``HEAD` object may also inline up to :confval:`rgw_max_chunk_size` of object data, for efficiency
+The ``HEAD`` object may also inline up to :confval:`rgw_max_chunk_size` of object data, for efficiency
and atomicity. This enables a convenenient tiering strategy: index pools
are necessarily replicated (cannot be EC) and should be placed on fast SSD
OSDs. With a mix of small/hot RGW objects and larger, warm/cold RGW
testcont
namespace: ``users.uid``
- Contains _both_ per-user information (RGWUserInfo) in "<user>" objects
+ Contains *both* per-user information (RGWUserInfo) in "<user>" objects
and per-user lists of buckets in omaps of "<user>.buckets" objects.
The "<user>" may contain the tenant if non-empty, for example::
example: ``default.7593.4__shadow_.488urDFerTYXavx4yAd-Op8mxehnvTI_1``
<marker>_<key>
-An example of a marker would be ``default.16004.1`` or `default.7593.4``.
+An example of a marker would be ``default.16004.1`` or ``default.7593.4``.
The current format is ``<zone>.<instance_id>.<bucket_id>``. But once
generated, a marker is not parsed again, so its format may change
freely in the future.