海量小文件存储在单个文件系统上并通过 NFS 共享，是否会显著增加数据损坏的几率？(´･_･`)

[helixzz]

背景： 公司有一批自己组建的服务器用于存储实验数据，约有 30~40 台左右的工作站会通过挂载 nfs 共享来读写上面的文件（ nfs 挂载参数： hard ， rw ， sync ）。数据大多是海量的小文件（文件类型 json 、 jpg ，数据量甚至大的时候会把 inode 用光），每台服务器的 RAID 阵列上是单个 ext4 文件系统，容量从 20TB 到 40TB 都有。

硬件环境： Supermicro X10 系列主板， E3-1231v3 ， 16GB ECC RAM LSI 9260-8i 阵列卡， 12x 4TB WD RE 系列企业级 SATA 硬盘， RAID5+HotSpare 或者 RAID6 。

软件环境： Ubuntu 12.04 LTS ， Linux 3.5.0-23-generic

————————

现在碰到的非常棘手的问题就是，服务器搭起来后，存了一二十 TB 数据，然后就开始大面积出现文件系统错误。比如 df -lh 会看到已用空间和可用空间不正常：

admin@nas1:~$ df -lh

Filesystem Size Used Avail Use% Mounted on

/dev/sda1 205G 31G 164G 16% /

/dev/sdb1 40T -308T 346T - /mnt/nas1

在 dmesg 里也有大量关于文件系统的错误：

[60467.013963] EXT4-fs error (device sdb1): ext4_mb_generate_buddy:741: group 12736, 0 clusters in bitmap, 4294955217 in gd

[60467.014350] EXT4-fs error (device sdb1): ext4_mb_generate_buddy:741: group 12739, 0 clusters in bitmap, 4294955232 in gd

[60467.192619] EXT4-fs error (device sdb1): ext4_mb_generate_buddy:741: group 12752, 10889 clusters in bitmap, 4294958419 in gd

以及，研发会报告说部分文件夹变成了文件，或者读写文件时报错提示 Input/Output Error 。

————————

我们在工作站上对单盘也有同样的使用方式（ 2TB 或者 3TB ，格式化成 ext4 ，开 NFS 共享给其他几十台机器），但很少碰到类似情况。现在不知道是因为单个文件系统太大，还是 RAID 卡的原因，还是因为大量小文件被多机器同时读写？

不知道有没有相关经验的童鞋指点一下。

[fcicq]

目测文件系统应该已经坏了, 换新内核再有问题应该往内核 bug 方向考虑了.

[helixzz]

@fcicq 几台不同内核版本的机器都出现这个问题。有 3.13.0-85-generic ， 3.5.0-23-generic ， 3.13.0-74-generic 等等。这么大体量的文件系统，而且是大量小文件， rsync 只有几 MB/s 的速度， fsck 一星期也修不完…都不知道这些数据该怎么处理了。目前我们正在一点一点拷贝最重要的部分到独立插几块硬盘的 PC 上，先做点备份……

[fcicq]

@helixzz 所以这种配置的系统应该把内存加到 64G 上 Solaris 跑 ZFS RAID-z2. 现在除了内存少了一点以外正是 ZFS 的推荐配置.

[fcicq]

@helixzz 另外你不用开发版内核你就没有机会上 LKML 反馈问题. 文件系统已经坏了就没法报告, 不是开发者想去查问题也根本没有头绪.

[helixzz]

@fcicq 请问在海量小文件的场景下 ZFS 的性能怎么样呢？因为涉及到冗余和校验，想必还是挺吃 CPU 的…然后我们又是开 nfs 给一大堆机器同时使用，可能有大量的随机读写。另外主要是自己不熟悉，不知道 ZFS 与场景的硬件 RAID 方案比可靠性和维护的方便程度有没有什么差别。

[fcicq]

@helixzz ZFS 的 RAID-z 比民用级的一切都好. 硬 RAID 是自讨没趣.

[xbb7766]

这 df 信息文件系统肯定问题大了。
以前就听说 ext4 有个 16TB 的坎。现在不知道有改善没。
那么大的卷最好还是考虑别的文件系统。

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/s-storage-fs.html

https://m.reddit.com/r/DataHoarder/comments/1uxg3r/til_cant_grow_ext4_past_16tb_without_o_64bit/

[helixzz]

@fcicq 感谢，我研究一下 ZFS 。

[helixzz]

@xbb7766 关于 16TB 的坎，有什么历史渊源吗？我知道 ext3 是最大只支持 16TB 。但把分区格式化成 ext4 的时候，实在是顺利得很…以前也确实没听说过有这么低的限制（ wikipedia 说是 1EiB ）。看了你发的链接，理论上 2012 年以后的内核和 e2fsprogs 都应该已经支持大于 16TB 的 ext4 卷了才对…

[helixzz]

@xbb7766 不过，考虑别的文件系统的确是正经事。在不太改变现有架构的情况下，似乎 XFS 是个不错的选择？

[xbb7766]

@helixzz
我最早是从家用 NAS 开始用 XFS ，因为 ARM 的 CPU 本来就弱， XFS 读写时开销比较小。后来仓库机上也用的这个，除了不能像 extfs 那样缩小卷，其他没觉得什么不便。
自己最大建过 15TB 的 XFS ，再大没试过。照 wikipedia 资料说最大可以 8EB 。

16TB 大概是 32 位系统的坎？因为按照 wikipedia 的资料 XFS 在 32 位系统下也有 16TB 限制。
https://en.wikipedia.org/wiki/XFS#Capacity

[xbb7766]

对了，关键的忘了。硬盘的 SMART 信息有出问题么？

[helixzz]

@xbb7766 32 位那就是 2^32 的限制了。我们用的都是 64bit 的 Ubuntu 。 RAID 卡没有报错（一直是 Optimal 状态），并且开启了 Patrol Read ，如果是硬盘硬件上的问题，我觉得 RAID 卡应该会告警的吧？ SMART 没有特别注意，但刚看了一下没有问题。而且这些 4TB RE4 也才用了一年。