Project

General

Profile

Actions

Bug #16842

closed

[keepstore] S3 driver should handle sub-second precision in timestamps

Added by Tom Clegg over 4 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
Keep
Target version:
Start date:
09/16/2020
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Story points:
-
Release relationship:
Auto

Description

Before deleting a block, in order to detect GC races, keepstore's trash worker compares the timestamp of the stored block to the timestamp provided by keep-balance in the trash list, which in turn comes from keepstore's "index" worker.

The stored block's timestamp comes from the Last-Modified header from an S3 "head object" response, which is RFC1123-formatted and therefore has no better than 1-second precision.

The index worker's timestamp comes from the LastModified XML tag in the S3 "list objects" response, which is RFC3339-formatted and potentially has a non-zero nanosecond part.

AWS and Google implementations of S3 always return zero nanoseconds in the "list objects" response, but Ceph/nautilus returns timestamps with milliseconds, which as a result will never match the RFC1123-formatted timestamp used by the trash worker.

To resolve this, the S3 index handler should truncate the nanosecond part when parsing timestamps.


Files

keepstore (23.4 MB) keepstore 7e503a238d67b79a9f87e50086ca217d4873726e-dev (go1.14) Tom Clegg, 09/17/2020 01:47 PM
keepstore_2.0.4.dev20200917174905-1_amd64.deb (8.26 MB) keepstore_2.0.4.dev20200917174905-1_amd64.deb Ward Vandewege, 09/17/2020 06:09 PM

Subtasks 1 (0 open1 closed)

Task #16844: Review 16842-s3-timestamp-precisionResolvedWard Vandewege09/16/2020

Actions
Actions

Also available in: Atom PDF