hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raghu Angadi (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-4584) Slow generation of blockReport at DataNode causes delay of sending heartbeat to NameNode
Date Thu, 26 Feb 2009 16:55:02 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12677059#action_12677059

Raghu Angadi commented on HADOOP-4584:

I don't see any advantage to (3), based on more details, it might not even be correct. The
requirement is that BlockReport should have "exact snapshot" of blocks... i.e. no changes
changes can happen to FSDataset from the time block report starts until it ends. Which thread
does it does not matter. Processing commands and block report in one thread makes sense since
those need to happen serially.

May be (3) still has some advantage : could you give a specific example that shows the advantage?

Fixing the block reports properly (with a directory scan once a day or so), i.e. "Option 3"
in a seperate jira is ok. But I would like to see that marked as blocker at least for 0.20
or 0.21. I for one am pretty tired of replying "oh, that is a known issue and we need fix"
every time users complain about it. Some users even had a separate process to constant scan
the directory tree to to keep the inode info in kernel memory.

> Slow generation of blockReport at DataNode causes delay of sending heartbeat to NameNode
> ----------------------------------------------------------------------------------------
>                 Key: HADOOP-4584
>                 URL: https://issues.apache.org/jira/browse/HADOOP-4584
>             Project: Hadoop Core
>          Issue Type: Bug
>          Components: dfs
>            Reporter: Hairong Kuang
>            Assignee: Suresh Srinivas
>             Fix For: 0.20.0
>         Attachments: 4584.patch, 4584.patch, 4584.patch, 4584.patch, 4584.patch, 4584.patch
> sometimes due to disk or some other problems, datanode takes minutes or tens of minutes
to generate a block report. It causes the datanode not able to send heartbeat to NameNode
every 3 seconds. In the worst case, it makes NameNode to detect a lost heartbeat and wrongly
decide that the datanode is dead.
> It would be nice to have two threads instead. One thread is for scanning data directories
and generating block report, and executes the requests sent by NameNode; Another thread is
for sending heartbeats, block reports, and picking up the requests from NameNode. By having
these two threads, the sending of heartbeats will not get delayed by any slow block report
or slow execution of NameNode requests.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message