Volume failure reported while disks seem fine

[#1]

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?

Best Regards

\Knut Nordin

[#2]

Couple of places you can check:
- Host Inspector in CM
- CM agent logs under /var/log/cloudera-scm-agent

[#3]

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?

[#4]

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.

 

Knut

[#5]

For a start, ensure your Cloudera Manager is also 5.2.1. We informally required that the versions be matched but it is now a requirement from 5.2 onwards. CM version should be equal or higher than CDH version.

Next, go to Cloudera Management services -> even search -> critical. See if the volume related error is listed. If so, please paste details here.

[#6]

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?

Regards

Knut

[#7 · Accepted solution]

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.

[#8]

Glad the issue is resolved, thanks for letting us know.

[#9]

Hi, 

can you tell us please how it was pointed out ? where to check if this is the case ? 

regards

[#10]

---

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.

HTH

[#11]

In my case I did moved the existing dn directory as it has very less data and started the services.

There was no disk failure or issue with fstab file or mounting.

[#12]

Yes even in my case fstab issue was not there. Rather i could clearly find the issue from datanode logs under /var/log/ and fix the issue. I have a blog on the same as below. Please comment on blog if it helps.

https://itdoctorharsha.wordpress.com/2019/08/23/hadoop-data-volume-failures-and-solution-cloudera/