[
https://issues.apache.org/jira/browse/HADOOP-15183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16822306#comment-16822306
]
Steve Loughran commented on HADOOP-15183:
-----------------------------------------
+proposal from [~mackrorysd]:
# incremental update of copy status as the operation proceeds (we could even
farm these off to the thread pool as a sequence of: copy, update).
# delete is postponed completely until the end of the operation, where each
1000+ paged delete is matched with an update of the metastore.
This would mean that the store was consistent with the bucket after every copy
operation, and no deletions took place until the entire copy had completed.
That way, even if there were partial permission failures during delete, you'd
be guaranteed to have one of: a complete source tree, a complete dest tree.
Cost:
* storage of list of copied files
* making sure each delete doesn't do anything about creating parent dir markers
* making sure the metadata updates only delete the files
* Also: New files added to source dir would get deleted if the delete
reenumerated the operation.
* Potentially slower (though as copy and delete are in the same thread that may
not hold)
We'd probably have to do something of: cache the initial list of files (that
first listing), but for larger operations revert to rerunning the LIST
sequence. Which costs $ and time.
Proposed: do the paged deletes in thread pool operations, which means that
partial delete failure may result in >1 outstanding delete page. before the
exception is discovered and escalated. Apart from the time lost, I don't see
this being too bad: the source tree may be partially deleted in either case.
What is key is for the metastore to be brought up to date with all deleted
files as they go
> S3Guard store becomes inconsistent after partial failure of rename
> ------------------------------------------------------------------
>
> Key: HADOOP-15183
> URL: https://issues.apache.org/jira/browse/HADOOP-15183
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
> Affects Versions: 3.0.0
> Reporter: Steve Loughran
> Assignee: Steve Loughran
> Priority: Blocker
> Attachments: HADOOP-15183-001.patch, HADOOP-15183-002.patch,
> org.apache.hadoop.fs.s3a.auth.ITestAssumeRole-output.txt
>
>
> If an S3A rename() operation fails partway through, such as when the user
> doesn't have permissions to delete the source files after copying to the
> destination, then the s3guard view of the world ends up inconsistent. In
> particular the sequence
> (assuming src/file* is a list of files file1...file10 and read only to
> caller)
>
> # create file rename src/file1 dest/ ; expect AccessDeniedException in the
> delete, dest/file1 will exist
> # delete file dest/file1
> # rename src/file* dest/ ; expect failure
> # list dest; you will not see dest/file1
> You will not see file1 in the listing, presumably because it will have a
> tombstone marker and the update at the end of the rename() didn't take place:
> the old data is still there.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
