Currently a call to flush_tier will enqueue a WT_TIERED_WORK_FLUSH work unit for the internal thread to dequeue and perform the work of actually copying a tiered object to the storage source. The user application thread will perform its work and enqueue units for all tables it has to flush. Then before returning to the user, it will wait for the enqueued work to be completed, by an internal thread.

The work of flushing an object is broken up into several smaller tasks that the internal thread performs in conn_tiered.c:wt_tier_do_flush:

• Call ss_flush to place the object in shared storage. The call could take a while.
• Flush updates to the metadata to indicate the object now exists in the cloud.
• Call ss_flush_finish to perform other activities such as making a copy in the storage source's caching area.

It occurs to me that the call to ss_flush_finish could be split apart from the other two tasks. This is desirable because the user thread is waiting for this flushing to complete and it would be good for the user thread to wait for the bare minimum of work to be done before returning to the user. The internal thread could generate and enqueue a new WT_TIERED_WORK_FLUSH_FINISH work unit to be performed after the flushing is done and the user thread is released from waiting.