Project

General

Profile

Feature #19295

[journal] issue journal event append + write operations in parallel

Added by Jason Dillaman about 7 years ago.

Status:
New
Priority:
Low
Assignee:
-
Target version:
-
% Done:

0%

Source:
Tags:
Backport:
Reviewed:
Affected Versions:
Pull request ID:

Description

Currently, the journal event needs to be safely committed to disk before the write operation can proceed. This is to ensure that the mirrored non-primary image is 100% consistent with the primary image. This, unfortunately, results in a 2x latency hit when the working set does not fit within the librbd writeback cache.

Instead, introduce new journal events for tracking "hot" objects. If an object is determined to be hot, append a journal record to describe which objects are hot. Once that event is safe, writes to hot objects can be performed in parallel with their associated journal event. An object cannot be evicted from the hot set until all its in-flight events+writes are committed.

When a primary image is opened (i.e. because the client crashed and was re-started or due to a failover event), after replaying all journal events (and rebuilding the hot set table from the associated event), all hot objects need to be read from disk and written to the journal as a write op.

Also available in: Atom PDF