You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-issues@hadoop.apache.org by "Todd Lipcon (JIRA)" <ji...@apache.org> on 2011/05/23 23:31:47 UTC
[jira] [Commented] (HDFS-1603) Namenode gets sticky if one of
namenode storage volumes disappears (removed, unmounted, etc.)
[ https://issues.apache.org/jira/browse/HDFS-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038245#comment-13038245 ]
Todd Lipcon commented on HDFS-1603:
-----------------------------------
ATM and I just brainstormed about this a little bit over some iced coffee. Though on the surface it doesn't look too hard to implement timeouts on namedir operations, it would actually have to be done in a lot of places (eg mkdirs/move calls on storage directories, writing edits, saving images, etc). Timing out some of these things isn't entirely straightforward, since the underlying calls aren't interruptible.
At some point we could attempt to tackle it, but looks like a complicated project. So, rather than trying to implement this in "software" for now, it's probably better to just recommend the proper NFS mount options when storing name dirs on NFS.
> Namenode gets sticky if one of namenode storage volumes disappears (removed, unmounted, etc.)
> ---------------------------------------------------------------------------------------------
>
> Key: HDFS-1603
> URL: https://issues.apache.org/jira/browse/HDFS-1603
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
> Affects Versions: 0.21.0
> Reporter: Konstantin Boudnik
>
> While investigating failures on HDFS-1602 it became apparent that once a namenode storage volume is pulled out NN becomes completely "sticky" until {{FSImage:processIOError: removing storage}} move the storage from the active set. During this time none of normal NN operations are possible (e.g. creating a directory on HDFS timeouts eventually).
> In case of NFS this can be workaround'd with soft,intr,timeo,retrans settings. However, a better handling of the situation is apparently possible and needs to be implemented.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira