Known Issues in HDFS

Learn about the known issues in HDFS, the impact or changes to the functionality, and the workaround.

OPSAPS-60958: The dfs.access.time.precision and dfs.namenode.accesstime.precision parameters are available in Cloudera Manager > HDFS > Configuration.
You must configure both the dfs.access.time.precision and dfs.namenode.accesstime.precision parameters with the same value as Cloudera Manager still sends both the parameters to HDFS service configuration.
OPSAPS-55788: WebHDFS is always enabled. The Enable WebHDFS checkbox does not take effect.
None.
Unsupported Features
The following HDFS features are currently not supported in Cloudera Data Platform:
OPSAPS-59321: The HDP 3.1.5 cluster with NameNode federation enabled does not support migration to the CDP 7.1.6 cluster.
None.
HDFS-15422: After upgrade from CDH to Cloudera Runtime 7 followed by a Name Node Failover, hdfs fsck command may report false negatives: “CORRUPT ReasonCode: SIZE_MISMATCH”.
Upgrade to maintenance releases 7.1.7+ or 7.2.9+.

Technical Service Bulletins

TSB 2022-604: GetContentSummary call performance issues with Apache Ranger HDFS plugin
With Apache Ranger enabled on the NameNode, getContentSummary calls in the Apache Hadoop Distributed File System (HDFS) lock for multiple seconds and can cause NameNode failover.
Knowledge article
For the latest update on this issue see the corresponding Knowledge article: TSB 2022-604: GetContentSummary call performance issues with Apache Ranger HDFS plugin
TSB 2022-549: Possible HDFS Erasure Coded (EC) data loss when EC blocks are over-replicated
Cloudera has detected a bug that can cause loss of data that is stored in HDFS Erasure Coded (EC) files in an unlikely scenario.
Some EC blocks may be inadvertently deleted due to a bug in how the NameNode chooses excess or over-replicated block replicas for deletion. One possible cause of over-replication is running the HDFS balancer soon after a NameNode goes into failover mode.
In a rare situation, the redundant blocks could be placed in such a way that one replica is in one rack, and few redundant replicas are in the same rack. Such placement causes a counting bug (HDFS-16420) to be triggered. Instead of deleting just the redundant replicas, the original replica may also be deleted.
Usually this is not an issue, because the lost replica can be detected and reconstructed from the remaining data and parity blocks. However, if multiple blocks in an EC Block Group are affected by this counting bug within a short time, the block cannot be reconstructed anymore. For example, 4 blocks are affected out of 9 for the RS(6,3) policy.
Another situation is recommissioning multiple nodes back into the same rack of the cluster where the current live replica exists.
Upstream JIRA
HDFS-16420
Knowledge article
For the latest update on this issue see the corresponding Knowledge article: TSB 2022-549: Possible HDFS Erasure Coded (EC) data loss when EC blocks are over-replicated