[
https://issues.apache.org/jira/browse/YARN-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13971784#comment-13971784
]
Jason Lowe commented on YARN-1940:
----------------------------------
Thanks for posting a patch, Rushabh. The patch will cause us to continue
trying to delete, but it will not report the failure to delete one or more
files. We need to return a non-zero return code from delete_path if we failed
to delete an entry, with the caveat that we shouldn't complain about an attempt
to delete a non-existent path. I'm thinking patterning it more like the logic
in delete_as_user would make sense, where we remember if there was an error and
will ultimately return an error, but we don't stop trying to delete on the
first error. delete_as_user reports the last error it received rather than the
first, but it conveys the general idea.
> deleteAsUser() terminates early without deleting more files on error
> --------------------------------------------------------------------
>
> Key: YARN-1940
> URL: https://issues.apache.org/jira/browse/YARN-1940
> Project: Hadoop YARN
> Issue Type: Bug
> Reporter: Kihwal Lee
> Assignee: Rushabh S Shah
> Attachments: YARN-1940.patch
>
>
> In container-executor.c, delete_path() returns early when unlink() against a
> file or a symlink fails. We have seen many cases of the error being ENOENT,
> which can safely be ignored during delete.
> This is what we saw recently: An app mistakenly created a large number of
> files in the local directory and the deletion service failed to delete a
> significant portion of them due to this bug. Repeatedly hitting this on the
> same node led to exhaustion of inodes in one of the partitions.
> Beside ignoring ENOENT, delete_path() can simply skip the failed one and
> continue in some cases, rather than aborting and leaving files behind.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
