[
https://issues.apache.org/jira/browse/HADOOP-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564542#action_12564542
]
Christian Kunz commented on HADOOP-2755:
----------------------------------------
At the time of the upgrade a single node mounted the home directories from the
wrong adminhost and did not get restarted with the correct version. This has
been fixed, but I suspect, all the blocks of this node needed to get
replicated. But this is less than 20,000 blocks. This should be handled easily
by dfs.
Also the namenode came out of safemode automatically, i.e. there were no
missing blocks, which you would expect from a massive failure of joining
datanodes.
60% cpu out of 400% cpu (there are 4 cpu's) is not much in my opinion. What is
strange compared to other namenodes is that the system usage of the CPU is
relatively high.
> dfs fsck extremely slow, dfs ls times out
> -----------------------------------------
>
> Key: HADOOP-2755
> URL: https://issues.apache.org/jira/browse/HADOOP-2755
> Project: Hadoop Core
> Issue Type: Bug
> Affects Versions: 0.16.0
> Environment: Jan 28 nightly build
> With patches 2095, 2119, and 2723
> Reporter: Christian Kunz
> Assignee: dhruba borthakur
> Priority: Blocker
> Fix For: 0.16.0
>
>
> I upgraded a Hadoop installation to the Jan 28 nightly build.
> DFS contains 2.4+ M files.
> Upgrade finished but not finalized.
> Before finalizing I wanted to run fsck on the DFS. It hardly progressed after
> 6 hours (not finished yet). With the '-files' option turned on, it lists
> about 300 entries in 10 minutes.
> And when I tried to list a subdirectory with 100,000 files, it repeatedly
> (about 20 attempts) timed out.
> Changing timeout from 1 to 10 minutes did not help.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
