)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":34930,"name":"Jianjian Huo","email":"jhuo@nvidia.com","username":"jhuo"},"change_message_id":"2dcadad314228d9e52ff864dec4bfba37f4f8509","unresolved":true,"context_lines":[{"line_number":20,"context_line":"The random jitter offset does not conflict with existing timestamp"},{"line_number":21,"context_line":"offset use cases. For versioned_writes: as long as unique_time"},{"line_number":22,"context_line":"middleware is placed after auth and before versioned_writes in the"},{"line_number":23,"context_line":"pipeline, the versioned_writes middleware will correctly apply its"},{"line_number":24,"context_line":"offset+\u003d1 for symlink objects on top of the jittered timestamp. For the"},{"line_number":25,"context_line":"reconciler: since a new misplaced object must be added to the misplaced"},{"line_number":26,"context_line":"container before the reconciler daemon processes it (a delay of many"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"c574d4f1_2b7efec7","line":23,"updated":"2026-01-05 06:00:40.000000000","message":"in order to have versioned_writes middleware to work, this patch also would need this small change to the Timestamp::__invert__:\n\n```\n    def __invert__(self):\n        inv_raw \u003d (MAX_RAW_TIME - self.raw) * PRECISION\n        if not self.hex_part:\n            inv_hex_part \u003d 0\n        else:\n            inv_hex_part \u003d MAX_HEX_PART - self.hex_part\n        return Timestamp(self._internal_format(inv_raw, inv_hex_part))\n```","commit_id":"8039590b137b5a0e4e8d6739bddecf1b36330a5f"}],"/PATCHSET_LEVEL":[{"author":{"_account_id":7847,"name":"Alistair Coles","email":"alistairncoles@gmail.com","username":"acoles"},"change_message_id":"475b08a30611383f7b6bfcb4ad083e14e9ad2fe4","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"cda277c9_3b007034","updated":"2026-01-02 10:49:05.000000000","message":"There\u0027s two aspects to this proposal that differ from https://review.opendev.org/c/openstack/swift/+/967738\n\n1. The random jitter is used to initialise the Timestamp offset (rather than kept distinct from offset).\n2. The jitter is only applied to object PUT requests.\n\nRe 1:\n- Consider two concurrent requests with the same float (deca-microsecond) time T that are assigned random jitter x and y where x \u003c y, i.e. they have Timestamps T_x and T_y where T_x is considered older than T_y.\n- If the older object is misplaced then when it is moved T_x offset will be incremented, potentially multiple times, becoming T_z. However, this object MUST remain the older object, so it must be guaranteed that T_z \u003c T_y i.e. that y \u003e\u003e x.\n- In this proposal I don\u0027t see how that can be guaranteed (it\u0027s arguably *probable* but it is not guaranteed).\n- In https://review.opendev.org/c/openstack/swift/+/967738 T_x and T_y would be separated by 16^6, so there is at least a guarantee that T_x can be incremented 16^6 times before T_x becomes greater than T_y.\n\nRe. 2\n- If we need to differentiate between object PUTs that occur in the same deca-microsecond, then why not object POSTs? and container POSTs? I think we have to assume that any client request type could be concurrent and consider the implication of colliding POSTs with different metadata.\n- On this point, we need to decide if we are *only* trying to address the so-far known problem case of client PUT requests with *identical* content going to encrypted EC fragments, or whether we are addressing the general case of any concurrent client request, including requests with different object data and/or metadata.\n- I do think that we may want to *tactically* defer applying jitter to POST requests until we are sure we understand the implications for on disk meta file naming, but IMHO that would be a tactical delay rather than a strategic decision to not address concurrent POST requests.","commit_id":"71c592337c2678d00036cd31692cef646a15b9db"},{"author":{"_account_id":34930,"name":"Jianjian Huo","email":"jhuo@nvidia.com","username":"jhuo"},"change_message_id":"09c485cdf94acdf9c47e0e0527cddb41275c6d5d","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"850e7801_7378bcb2","in_reply_to":"cda277c9_3b007034","updated":"2026-01-03 19:54:14.000000000","message":"Re Re. 1\n```\nIf the older object is misplaced then when it is moved T_x offset will be incremented, \npotentially multiple times, becoming T_z. However, this object MUST remain the older object, \nso it must be guaranteed that T_z \u003c T_y i.e. that y \u003e\u003e x.\n```\nthis would be a bug of reconciler if it allows this to happen, this is the same case as this: one object became misplaced object due to policy change in the middle of upload, later user re-upload it again into the correct policy and container; when reconciler moves the misplaced object to the correct policy and container, oops, there is a same object there already with newer timestamp.\n\nLuckily, reconciler is already handling this case correctly, it will use abort the copying and delete the old misplaced object, see: https://github.com/NVIDIA/swift/blob/master/swift/container/reconciler.py#L532-L547\n\nRe Re. 2\n```\nIf we need to differentiate between object PUTs that occur in the same deca-microsecond,\nthen why not object POSTs? and container POSTs? I think we have to assume that any client\nrequest type could be concurrent and consider the implication of colliding POSTs with different metadata.\n```\n\nSo far we have only seen problems caused by concurrent EC PUTs with same timestamp, and even those concurrent EC same-time PUTs have identical data. For object POSTs with EC policy, each fragment node will store a full copy of metadata, so concurrent same-time POSTs won\u0027t cause any problem when they have identical metadata. The case of ``colliding POSTs with different metadata`` is only possible in theory for now, and if we see that happens later, we can simply add the support of it into the new ``unique_time`` middleware at here: https://review.opendev.org/c/openstack/swift/+/972032/1/swift/common/middleware/unique_time.py#41. This applies to container PUT/POST as well.","commit_id":"71c592337c2678d00036cd31692cef646a15b9db"}]}