我有一个群集启动并运行（HDP-2.3.0.0-2557），它由10个物理服务器（2个管理服务器和8个数据节点组成，所有这些都是健康的）。群集（HDFS）在一个月前加载了大约4Tb数据的初始数据集。最重要的是，加载后没有任何丢失或损坏块的报告！
我在完全没有使用系统一个月后在HDFS摘要下加载了Ambari仪表板 - 阻止错误部分我看到“28缺失/ 28正在复制”。这些服务器根本没有使用，特别是没有地图减少作业，也没有新文件读取或写入HDFS。 28块现在怎么可能被报告为腐败？
驻留在一个4Tb磁盘上的原始数据源没有丢失的块，没有损坏的文件或任何类型的东西，并且工作得很好！使用HDFS将数据重复三次应该可以保护我免受文件丢失/损坏的影响。
我已经运行了所有建议的fsck命令，可以看到如下行：
/user/ambari-qa/examples/input-data/rawLogs/2010/01/01/01/40/log05.txt: MISSING 1 blocks of total size 15 B...........
/user/ambari-qa/examples/src/org/apache/oozie/example/DemoMapper.java: CORRUPT blockpool BP-277908767-10.13.70.142-1443449015470 block blk_1073742397
我确信我的经理Hadoop是前进的方向，因为它具有令人印象深刻的弹性声明但这个例子证明（至少对我来说）HDFS是否已经落伍？也许我做错了什么但当然我不应该在文件系统中搜索丢失的块。我需要回复给我的经理一个解释，如果这28个丢失文件中的一个是关键的，那么HDFS会让我陷入热水！在这个时候，我的经理认为HDFS不适合用途！
我必须遗漏某些东西或做错事，肯定一式三份存储的文件/块丢失的可能性要小3倍？！这个概念是，如果一个数据节点脱机，那么文件被标记为复制下并最终复制到另一个数据节点。
总结：安装了默认的HDP安装，并启动了所有服务。 4Tb数据复制到HDFS而没有报告错误（所有块都以默认的三重复制存储）。一切都离开了1个月。 HDFS摘要报告28个丢失的文件（遇到的9个数据节点中没有任何磁盘错误）。
还有其他人有类似的经历吗？
“hdfs fsck /”命令的最后一节输出：
Total size: 462105508821 B (Total open files size: 1143 B)
Total dirs: 4389
Total files: 39951
Total symlinks: 0 (Files currently being written: 13)
Total blocks (validated): 41889 (avg. block size 11031667 B) (Total open file blocks (not validated): 12)
********************************
UNDER MIN REPL'D BLOCKS: 40 (0.09549046 %)
dfs.namenode.replication.min: 1
CORRUPT FILES: 40
MISSING BLOCKS: 40
MISSING SIZE: 156470223 B
CORRUPT BLOCKS: 28
********************************
Minimally replicated blocks: 41861 (99.93316 %)
Over-replicated blocks: 0 (0.0 %)
Under-replicated blocks: 0 (0.0 %)
Mis-replicated blocks: 0 (0.0 %)
Default replication factor: 3
Average block replication: 2.998138
Corrupt blocks: 28
Missing replicas: 0 (0.0 %)
Number of data-nodes: 8
Number of racks: 1
FSCK ended at Thu Dec 24 03:18:32 CST 2015 in 979 milliseconds
The filesystem under path '/' is CORRUPT
感谢阅读！