@Noel_0317 The directory /hadoop/dfs/name/ might be your Namenode data directory that contains the metadata in the form of fsimage and edits. So won't recommend deleting it if that's the case. You can confirm if this directory is indeed the NN data directory by checking the HDFS configuration. If the cluster is working and still taking writes, you can verify if the Namenode Data dir has been changed to a different mount point if the latest data available on it is from July.   ... View more

@Noel_0317 If you want to know how the Datanode got upto 705GB, you will need to do a du at the Linux filesystem level for the datanode blockpool. For ex : du -s -h /data/dfs/dn/current/BP-331341740-172.25.35.200-1680172307700/ /data/dfs/dn/ ==> Datanode data dir BP ==> Blockpool used by the datanode The above should return 705GB. The Blockpool will contain the subdir which would be holding the File blocks present on this specific datanode. When you run 'hdfs dfs -du' it takes the entire HDFS storage into account.   ... View more

Did you make any changes at the KDC end prior to seeing this issue? Are there any other services hosted on this node that are working fine? ... View more

@Crash you can set up load balance at a disk level for the Datanodes. Refer : https://docs.cloudera.com/documentation/enterprise/5-16-x/topics/admin_dn_storage_balancing.html ... View more

I would suggest keeping one jar file at a time and checking.   1) /home/hadoop/hbase/hbase-2.5.5/lib/hbase-shaded-netty-4.1.4.jar!/META-INF/native/liborg_apache_hbase_thirdparty_netty_transport_native_epoll_x86_64.so   2) /home/hadoop/hbase/hbase-2.5.5/lib/phoenix-client-hbase-2.5-5.1.3.jar!/META-INF/native/liborg_apache_hbase_thirdparty_netty_transport_native_epoll_x86_64.so ... View more

https://docs.cloudera.com/documentation/enterprise/6/6.3/topics/phoenix_installation.html#concept_ysq_t4n_c3b ... View more