12-16-2014 05:00 AM
I just upgraded our cluster from CDH 5.0.1 to 5.2.1, using parcels and following the provided instructions.
After the upgrade has finished, the health test "Data Directory Status" is critical for one of the data nodes. The reported error message is "The DataNode has 1 volume failure(s)". By running 'hdfs dfsadmin -report' I can also confirm that the available HDFS space on that node is approximately 4 TB less than on the other nodes, indicating that one of the disks is not being used.
However, when checking the status of the actual disks and regular file system we can not find anything that seems wrong. All disks are mounted and seem to be working as they should. There is also an in_use.lock file in the dfs/nn directory on all of the disks.
How can I get more detailed information about which volume the DataNode is complaining about, and what the issue might be?
12-17-2014 12:49 AM
Thank you for the suggestions!
Host Inspector reports that everything is OK. I have checked the agent logs and also the log for the DataNode, but can not really find anything that gives any clues about this particular error.
Is there a command for making the DataNode report which physical directories it is using and what it thinks their status is?
12-18-2014 02:44 AM
Not sure if this is helpful, but here are some charts of volume failures and disk capacity the faultly node, and for a healthy one as reference. The strange thing is that all disks seem to be in use on both nodes, but the total configured capacity is different.
12-18-2014 04:49 PM
12-18-2014 11:53 PM
I can confirm that CM is running version 5.2.1, so that should not be an issue.
When searching for critical log messages I came across these:
It appears that another namenode 56559@datanode_hostname has already locked the storage directory
datanode_hostname:50010:DataXceiver error processing WRITE_BLOCK operation src: /10.8.19.28:37029 dst: /10.8.19.14:50010
We have only ever had one namenode, and none on the datanode host, so I am a bit confused by what the first message really means. The second one I suspect might be a secondary failure of the first one?
01-02-2015 12:14 AM
The source of this error has been found. It turned out that /etc/fstab on this node was badly configured, so that one of the disks was mounted twice as two separate data directories. Interestingly, this has not been causing any visible errors until upgrading to CDH 5.2.1. Nice that it was pointed out to us by this version though.
12-10-2016 03:28 PM
can you tell us please how it was pointed out ? where to check if this is the case ?
Here's one way of checking for duplicate mounts:
mount |wc -l > a mount |sort -u|uniq|wc -l > b cmp a b
If there's no output, there are no duplicate mounts.