我已经启动并运行了一个集群（hdp-2.3.0.0-2557），它包含10个物理服务器（2个管理服务器和8个数据节点，所有这些都是正常的）。集群（hdfs）在一个月前加载了一个大约4tb数据的初始数据集。最重要的是，加载后没有任何丢失或损坏块的报告！
在一个月没有使用系统之后，我加载了ambari Jmeter 板，在hdfs摘要-块错误部分，我看到“28 missing/28 under replicated”。服务器根本没有被使用，特别是没有map reduce作业，也没有读写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不适合这个目的！
我一定是遗漏了什么或做错了什么，以一式三份的形式存储的文件/块丢失的可能性肯定是原来的三倍？！其概念是，如果一个数据节点脱机，那么一个文件将被标记为复制不足，并最终复制到另一个数据节点。
总而言之：hdp的默认安装是在所有服务都已启动的情况下安装的。复制到hdfs的4tb数据，没有报告错误（所有数据块都以默认的三重复制方式存储）。一切都静置了一个月。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

感谢阅读！