[
https://issues.apache.org/jira/browse/HADOOP-13611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15490834#comment-15490834
]
Chris Nauroth commented on HADOOP-13611:
----------------------------------------
bq. That exists() check is superfluous; on s3 it add an extra 1-4 HTTP GETs
These checks were added in HADOOP-8634 to prevent some logging noise during
{{FileSystem#close}} if delete-on-exit tries to delete a path that doesn't
exist. I never saw that happen myself, so I don't know exactly which log
messages were getting triggered. If we revert these checks, then we need to
check for those log messages, and if still present, come up with a different
solution for suppressing them.
bq. This is easy to do, but low priority, as it is generally used in testing
rather than production.
I know at least Hive and HBase use it in production code, though I believe it's
less critical path than other bottlenecks we've been reviewing.
> FileSystem/s3a processDeleteOnExit to skip the exists() check
> -------------------------------------------------------------
>
> Key: HADOOP-13611
> URL: https://issues.apache.org/jira/browse/HADOOP-13611
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs, fs/s3
> Affects Versions: 2.7.3
> Reporter: Steve Loughran
> Priority: Minor
>
> If you look at {{FileSystem.processDeleteOnExit()}}, it does an exists()
> check for each entry, before calling delete().
> That exists() check is superfluous; on s3 it add an extra 1-4 HTTP GETs
> This could be fixed with a subclass in s3a to avoid it, but as the call is
> superfluous in *all* filesystems, it could be removed in {{FileSystem}} and
> so picked up by all object stores.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
