Deuxfleurs/garage
41
56
Fork 73
Code Issues 99 Pull requests 14 Releases 30 Wiki Activity

Ensure increasing version timestamps when writing new object versions #543

Merged
lx merged 6 commits from increasing-timestamps into main 2023-10-24 10:07:17 +00:00
Conversation 0 Commits 6 Files changed 3 +58 -42
lx commented 2023-04-18 16:03:45 +00:00
Owner
Copy link

Jepsen testing proved that S3 PutObject/GetObject is not linearizable in Garage. That's not an issue, as it was never intended to be. This PR does not fix this.

However there are some properties that objects are supposed to respect, and in particular, that writing a new object version does in fact overwrite older versions. More precisely, in the following sequence of events: WRITE(X=A); WRITE(X=B); READ(X), the last READ(X) will return B.

Jepsen testing showed that in current Garage versions, this was not always the case, due to the fact that the generated timestamps are not always in increasing order:

  • the version returned by a GetObject is the one with the highest internal timestamp

  • if the clocks on two nodes are diverging, a node B might do a write strictly after a node A but in it's local time it thinks that that write is happening before

  • previously, there was no check that the timestamp was strictly higher than the timestamp of the versions that have been inserted before

This PR adds the following fixes:

  • In PutObject, the previous version is fetched when generating the timestamp, to ensure that the new timestamp is larger than any version that was there before. This adds one RPC RTT to PutObject, but Garage tries to do that RPC in parallel with receiving the object's data, to minimize the time it takes: on large objects, the difference should be invisible.

  • Similar logic is also added to CreateMultipartUpload

  • In DeleteObject, a delete marker is always added, with an increasing timestamp as well

Jepsen testing showed that this improved the situation.

Jepsen testing proved that S3 PutObject/GetObject is not linearizable in Garage. That's not an issue, as it was never intended to be. This PR does not fix this. However there are some properties that objects are supposed to respect, and in particular, that writing a new object version does in fact overwrite older versions. More precisely, in the following sequence of events: WRITE(X=A); WRITE(X=B); READ(X), the last READ(X) will return B. Jepsen testing showed that in current Garage versions, this was not always the case, due to the fact that the generated timestamps are not always in increasing order: - the version returned by a GetObject is the one with the highest internal timestamp - if the clocks on two nodes are diverging, a node B might do a write strictly after a node A but in it's local time it thinks that that write is happening before - previously, there was no check that the timestamp was strictly higher than the timestamp of the versions that have been inserted before This PR adds the following fixes: - In PutObject, the previous version is fetched when generating the timestamp, to ensure that the new timestamp is larger than any version that was there before. This adds one RPC RTT to PutObject, but Garage tries to do that RPC in parallel with receiving the object's data, to minimize the time it takes: on large objects, the difference should be invisible. - Similar logic is also added to CreateMultipartUpload - In DeleteObject, a delete marker is always added, with an increasing timestamp as well Jepsen testing showed that this improved the situation.
lx force-pushed increasing-timestamps from d98bf45be6 to d39c5c6984 2023-04-18 16:05:29 +00:00 Compare
lx added the
kind
correctness
 label 2023-04-19 10:19:06 +00:00
lx force-pushed increasing-timestamps from d39c5c6984 to 03490d41d5 2023-04-19 10:19:23 +00:00 Compare
lx changed target branch from main to next 2023-06-13 12:53:36 +00:00
lx changed target branch from next to main 2023-06-13 13:16:04 +00:00
lx force-pushed increasing-timestamps from ad4a793262 to cb5199aed0 2023-06-13 13:30:51 +00:00 Compare
lx added this to the v1.0 milestone 2023-06-14 12:23:52 +00:00
lx force-pushed increasing-timestamps from cb5199aed0 to 3d6ed63824 2023-10-18 14:38:24 +00:00 Compare
lx added 1 commit 2023-10-18 14:38:33 +00:00
cargo fmt
All checks were successful
continuous-integration/drone/push Build is passing
Details
continuous-integration/drone/pr Build is passing
Details
continuous-integration/drone Build is passing
Details
d146cdd5b6
lx added 2 commits 2023-10-20 11:37:48 +00:00
s3 api: also ensure increasing timestamps for create_multipart_upload
All checks were successful
continuous-integration/drone/push Build is passing
Details
continuous-integration/drone/pr Build is passing
Details
8686cfd0b1
lx changed title from WIP: Ensure increasing version timestamps in PutObject to WIP: Ensure increasing version timestamps when writing new object versions 2023-10-20 11:37:59 +00:00
lx added 1 commit 2023-10-20 11:56:50 +00:00
DeleteObject: always insert a deletion marker with a bigger timestamp than everything before
All checks were successful
continuous-integration/drone/push Build is passing
Details
continuous-integration/drone/pr Build is passing
Details
continuous-integration/drone Build is passing
Details
c82d91c6bc
lx changed title from WIP: Ensure increasing version timestamps when writing new object versions to Ensure increasing version timestamps when writing new object versions 2023-10-24 10:05:59 +00:00
lx merged commit 75d5d08ee1 into main 2023-10-24 10:07:17 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
action
check-aws
The behaviour should be checked against AWS S3

  
action
discussion-needed
We need to discuss if the feature is desirable and/or better specify the envisioned behavior or technical implementation

  
action
for-external-contributors
Core team does not plan working on this in the near future however an external contribution will be reviewed & merged

  
action
for-newcomers
An issue that should be newcomer friendly.

  
action
more-info-needed
More information is needed to investigate this issue

  
action
need-funding
This issue represents lots of work, we need to find money to pay our core team work

  
action
triage-required
It's not very clear what we want to do with this issue yet, more thoughts is required

  
kind
correctness
Issues of theoretical correctness that may impact edge-case scenarios

  
kind
ideas
For abstract ideas/proposal to make Garage better, to better communicate our not yet achieved aims

  
kind
improvement
Feature requests that do not fall in other categories

  
kind
performance
Deceptive performance observed OR idea to improve performances

  
kind
testing
Functional tests, integration tests, Jepsen, etc.

  
kind
usability
Propositions to make Garage easier to operate, by improving error reporting, CLI, etc.

  
kind
wrong-behavior
Unintended behavior

  
prio
critical
Could impact integrity or availability of production clusters

  
prio
low
For issues that we don't want to spend time on until made absolutely necessary

  
scope
admin-api
Issues concerning the administration API

  
scope
background-healing
Background healing covers repair tasks, anti-entropy, merkle trees, etc. ; everything related to replicating data appropriately.

  
scope
build
Issues with Nix, Drone, Rust Compiler, etc.

  
scope
documentation

  
scope
k8s
Kubernetes related, including Helm Charts

  
scope
layout
Linked to the cluster layout and storage management

  
scope
metadata
Metadata Engine (LMDB, sqlite, etc.)

  
scope
ops
Operations related to operations/maintenance issue, tooling related (like CLI missing info ; impossible, too dangerous, too complicated migration, etc.)

  
scope
rpc
Linked to RPC

  
scope
s3-api
Related to the S3 API (especially compatibility issues).

  
scope
security
Cryptography-related, auth-related, authorization-related issues

  
scope
telemetry
OpenTelemetry (traces, metrics, etc.)

No labels
action
check-aws
action
discussion-needed
action
for-external-contributors
action
for-newcomers
action
more-info-needed
action
need-funding
action
triage-required
kind
correctness
kind
ideas
kind
improvement
kind
performance
kind
testing
kind
usability
kind
wrong-behavior
prio
critical
prio
low
scope
admin-api
scope
background-healing
scope
build
scope
documentation
scope
k8s
scope
layout
scope
metadata
scope
ops
scope
rpc
scope
s3-api
scope
security
scope
telemetry
Milestone
Clear milestone
No items
No milestone
v1.0
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Deuxfleurs/garage#543
No description provided.
Delete branch "increasing-timestamps"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?