[
https://issues.apache.org/jira/browse/HADOOP-16382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867782#comment-16867782
]
Steve Loughran commented on HADOOP-16382:
-----------------------------------------
Patch up. Issue observed while trying to debug a mismatch in DDB write counts
in a HADOOP-15183 test under load; the debug level logs implied that a newly
written file was still being updated in S3Guard on an existence check, because
the timestamps were different.
It'd be nice if we actually got a timestamp off AWS on the completion of the
PUT/POST call, so we'd have the actual value to put into the metadata. As it
is, we don't, not until the first HEAD/LIST gives us the value.
> clock skew can cause S3Guard to think object metadata is out of date
> --------------------------------------------------------------------
>
> Key: HADOOP-16382
> URL: https://issues.apache.org/jira/browse/HADOOP-16382
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
> Affects Versions: 3.3.0
> Reporter: Steve Loughran
> Priority: Minor
>
> When a S3Guard entry is added for an object, its last updated flag is taken
> from the local clock: if a getFileStatus is made immediately afterwards, the
> timestamp of the file from the HEAD may be > than the local time, so the DDB
> entry updated.
> This is even if the clocks are *close*. When updating an entry from S3, the
> actual timestamp of the file should be used to fix it, not local clocks
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
