Ceph

h1. RADOS Object Temperature Monitoring

h3. Summary

RADOS level tiering requires a way to identify objects which are infrequently read or written (cold objects).  To that end, RADOS needs to expose a way for users to efficiently find cold objects.

h3. Owners

* Samuel Just (Inktank)

* Name (Affiliation)

* Name

h3. Interested Parties

* Samuel Just (Inktank)

* Loic Dachary <loic@dachary.org>

* Kai Zhang (Cisco)

* Name

h3. Current Status

RADOS currently exposes information about the last modification time, but not about the last read time.  In addition, there is no efficient way to find cold objects save for iterating over a pool.

h3. Detailed Description

There are two main challenges:

# Providing an upper bound on the most recent access for an object without maintaining an atime

# Allowing the client to efficiently find objects which have a sufficiently old atime

We can provide 1. through an api like:

ObjectFilterHandle IoCtx::open_object_filter();

void IoCtx::close_object_filter(ObjectFilterHandle handle);

void IoCtx::get_object_filter(ObjectFilterHandle handle, ObjectFilter *filter);

void IoCtx::remove_object_filter(ObjectFilterHandle handle);

bool ObjectFilter::maybe_accessed(const std::string &oid, const std::string &namespace) const;

A tiering system could use this interface to obtain an ObjectFilter which would tell it whether a particular object was possibly accessed over the lifetime of the filter.  One approach to implementing this would be to add filter open, close, and removal events to the OSDMap as with snapshots.  PGs would then, upon processing an OSDMap, check for filter events and update local filters accordingly.  A simple option to handle OSD failure to be for a new primary upon going active to simply create replacement filters which report that all objects might have been modified.  get_object_filter obtains the set of filters from each PG and maybe_accessed queries the appropriate filter for the object queried.

There seem to be two approaches for 2.  One is for the client to simply use the existing rados pool iteration facilities to walk through the set of objects in the pool and compare them against filters which have been obtained.  The second would be for the OSD scrub mechanism to call into user provided code with each object and the set of stored filters.  The user provided code (scrub class?) could send a message to a tiering service based on the object and filters to satisfy a particular tiering policy.

h3. Work items

h3. Coding tasks

# Task 1

# Task 2

# Task 3

h3. Build / release tasks

# Task 1

# Task 2

# Task 3

h3. Documentation tasks

# Task 1

# Task 2

# Task 3

h3. Deprecation tasks

# Task 1

# Task 2

# Task 3