hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Lowe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-1940) deleteAsUser() terminates early without deleting more files on error
Date Wed, 16 Apr 2014 18:32:24 GMT

    [ 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)

Mime
View raw message