海量小文件存储在单个文件系统上并通过 NFS 共享，是否会显著增加数据损坏的几率？(´･_･`)
helixzz · 2016-06-15 14:23:30 +08:00 · 4084 次点击这是一个创建于 3083 天前的主题，其中的信息可能已经有所发展或是发生改变。
背景： 公司有一批自己组建的服务器用于存储实验数据，约有 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 卡的原因，还是因为大量小文件被多机器同时读写？
不知道有没有相关经验的童鞋指点一下。
 |
1
fcicq 2016-06-15 14:33:27 +08:00
目测文件系统应该已经坏了, 换新内核再有问题应该往内核 bug 方向考虑了.
|
 |
2
helixzz OP @fcicq 几台不同内核版本的机器都出现这个问题。有 3.13.0-85-generic ， 3.5.0-23-generic ， 3.13.0-74-generic 等等。这么大体量的文件系统，而且是大量小文件， rsync 只有几 MB/s 的速度， fsck 一星期也修不完…都不知道这些数据该怎么处理了。目前我们正在一点一点拷贝最重要的部分到独立插几块硬盘的 PC 上，先做点备份……
|
|
3
fcicq 2016-06-15 15:12:07 +08:00
@helixzz 所以这种配置的系统应该把内存加到 64G 上 Solaris 跑 ZFS RAID-z2. 现在除了内存少了一点以外正是 ZFS 的推荐配置.
|
|
4
fcicq 2016-06-15 15:19:40 +08:00
@helixzz 另外你不用开发版内核你就没有机会上 LKML 反馈问题. 文件系统已经坏了就没法报告, 不是开发者想去查问题也根本没有头绪.
|
|
5
helixzz OP @fcicq 请问在海量小文件的场景下 ZFS 的性能怎么样呢？因为涉及到冗余和校验，想必还是挺吃 CPU 的…然后我们又是开 nfs 给一大堆机器同时使用，可能有大量的随机读写。另外主要是自己不熟悉，不知道 ZFS 与场景的硬件 RAID 方案比可靠性和维护的方便程度有没有什么差别。
|
 |
7
xbb7766 2016-06-15 15:33:24 +08:00 via Android
这 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/ |
|
9
helixzz OP @xbb7766 关于 16TB 的坎，有什么历史渊源吗？我知道 ext3 是最大只支持 16TB 。但把分区格式化成 ext4 的时候，实在是顺利得很…以前也确实没听说过有这么低的限制（ wikipedia 说是 1EiB ）。看了你发的链接，理论上 2012 年以后的内核和 e2fsprogs 都应该已经支持大于 16TB 的 ext4 卷了才对…
|
|
11
xbb7766 2016-06-15 16:55:36 +08:00
@helixzz
我最早是从家用 NAS 开始用 XFS ，因为 ARM 的 CPU 本来就弱， XFS 读写时开销比较小。后来仓库机上也用的这个，除了不能像 extfs 那样缩小卷，其他没觉得什么不便。 自己最大建过 15TB 的 XFS ，再大没试过。照 wikipedia 资料说最大可以 8EB 。 16TB 大概是 32 位系统的坎？因为按照 wikipedia 的资料 XFS 在 32 位系统下也有 16TB 限制。 https://en.wikipedia.org/wiki/XFS#Capacity |
|
12
xbb7766 2016-06-15 17:12:53 +08:00
对了，关键的忘了。硬盘的 SMART 信息有出问题么？
|
Select Language