df -h统计的空间比实际使用的少

[qq_41066285]

在使用linux集群时，发现的使用空间很异常。
实际/share/目录下文件使用了22T的空间，但df -h统计出来挂载到/share/目录的硬盘才使用了5.3T。
其他硬盘也完全没有这么大的空间去放下这个统计结果之间差了15T的文件。
求大神告诉一下是什么问题，怎么解决？
或者有什么方法和命令可以查看到底哪里出错了？

[ckc]

你怎么看到/share有22T内容的？

[qq_41066285]

du -sh /share 看的

[qq_41066285]

引用 1 楼 ckc 的回复:

你怎么看到/share有22T内容的？

用 du -sh /share 看的

[qq_41066285]

引用 1 楼 ckc 的回复:

你怎么看到/share有22T内容的？

ps. 在 du -sh /share/ 的时候，有一些这样的报错信息：
du: cannot access `/file/path': Input/output error
都是一些小的图片文件，大概几百个。

类似这样的文件：
-rw-r--r--. 1 root root 5977 Apr 4 02:23 ENSG00000200087.box_point.png
-rw-r--r--. 1 root root 21255 Apr 4 02:23 ENSG00000200087.data.xls
-?????????? ? ? ? ? ? ENSG00000200795.box_point.png
-rw-r--r--. 1 root root 20266 Apr 4 02:23 ENSG00000200795.data.xls

[ckc]

这么看可能是文件系统损坏了
是啥文件系统？用相应的工具修复一下看看吧
修复之前建议备份一下数据

[qq_41066285]

引用 5 楼 ckc 的回复:

这么看可能是文件系统损坏了
是啥文件系统？用相应的工具修复一下看看吧
修复之前建议备份一下数据

整个 /share/ 22T 备份起来压力很大啊，没那么多硬盘。。。
是GPT文件系统。

[ckc]

没有备份迟早都是死路一条，不过这是另一个问题，你们可以赌下运气
那你可以先扫描一下，别处理，比如fsck就有-n参数可以用
看看是不是文件系统问题
另外gpt不算是文件系统，这只是分区方式
最后，没把握自己处理还是找人来帮忙看看，不然你数据又没备份，又没什么经验，很容易把小问题搞成大问题的

[qq_41066285]

引用 7 楼 ckc 的回复:

没有备份迟早都是死路一条，不过这是另一个问题，你们可以赌下运气
那你可以先扫描一下，别处理，比如fsck就有-n参数可以用
看看是不是文件系统问题
另外gpt不算是文件系统，这只是分区方式
最后，没把握自己处理还是找人来帮忙看看，不然你数据又没备份，又没什么经验，很容易把小问题搞成大问题的

谢谢，国庆节没看，不好意思，刚刚看了一下，df -h 的显示又正常了。。。
就国庆的时候关机了8天，很是懵逼。。。