卓思网 - Joomla Choice

     近来工作中要构建一个能够存储10T级左右别图片文件的图片存储系统，日增长6G左右的图片。面对这个系统，我又碰到了那个老问题，就是文件系统的选型。早在两年前，我就针对linux系统中几种流行的文件系统进行过考察和测试工作。当时的reiserfs 3.x 是让我非常满意的文件系统，reiserfs文件系统没有inode的局限，使用B+tree的索引形势来查找文件，效率是非常德高，特别是在小文件的存储效率上明显超出ext3很多（iozone测试佐证）。格式化效率和支持最大8T的文件系统容量上也都非常的不错，只是mount reiserfs的时候稍微显得有些缓慢。当时的reiserfs 3.x版本是对于linux 图片文件系统非常理想的选择。

     然而，就在我们期盼着reiser4的成熟之时，namesys的灵魂，reiser之父 Hans Reiser 因为感情问题翻了错误。（程序员还是应该多关心人家啊！）谋杀罪名成立，被判入狱。在我这次选型的时候，还是首先选择了reiser4，但是由于reiser4没有被众多的linux kernel引入，虽然据说官方网站有介绍用reiserfs 3.x的内核模块修改后来支持reiser4的文章，但是在我想做测试的时候官方网站也挂掉了，目前reiser4的小组仍然保持开发，但是有评价代码效率和质量都不够理想。个人能力有限，在AS5 64bit系统上尝试编译reiserfs 3.19的progs的时候也碰到了问题，没有人维护的代码我最终还是放弃了选型候选。

     那么让我们来看看现在我们还有什么可以选择吧。ext3 ext4 jfs xfs这四种文件系统中ext4现在还只有beta版本，所以暂时放弃列入候选，不过目前从口碑上来看ext4并没有什么让大家眼前一亮的性能提升。下面再来看xfs，这个文件系统诞生于sgi图形工作站上，被移植到linux上依赖表现还是比较稳定的，特别是在500M以上大文件的IO性能上非常突出，然而，我们今天要选型的是图片文件系统，我们常用的网络图片尺寸在16K~256K之间。而且xfs的大量删除效率非常差，所以在这个系统的选择中，我也放弃了xfs，备份系统上针对大文件的存储到是非常不错的选择。

     剩下就是ext3和jfs了，ext3大家再熟悉不过了，一个中庸的文件系统，但是广为流传。jfs是来自于IBM的手笔，早在5，6年前在AIX上面使用它的时候，我就对他的动态伸缩扩展能力表示钦佩，下面我们用测试数据来说明我们的选择吧。在展示结果之前，我先介绍一下两个文件系统，ext3最大支持8T的linux文件系统，是一个基于预分配inode的文件系统，由于linux文件系统最大的block为4K，所以他在linux最大支持8T，另外也是由于它的inode是预分配死的。所以如果你大量存储小于4K的文件，你文件系统的空间利用率会非常的低。从实践中大家也都有所了解吧？用df -h看看你们的大文件系统吧，你们就清楚了。另外在创建6.9T的测试ext3文件系统的时候，我实在无法忍受创建inode table的速度，6.9T文件系统，要创建5万多个inode table 在一台双志强，4G内存的 HP DL 360G5 RedHat AS5 64的服务器上，花去了足足15分钟以上去做inode table的创建，这一点实在是难以忍受。相反的同样的环境条件下jfs的创建速度不超过5S，这和他的动态文件系统，动态inode创建的设计优势不无关系。另外jfs是64bit unix上面移植而来，真正的64bit文件系统，可以支持最大512T的文件系统，动态扩展收缩文件系统。这些优势都是ext3所不能媲美的。

测试命令/usr/local/bin/iozone -g 256k -n 16k -a  针对16K致256K的文件测试。

Using maximum file size of 256 kilobytes.
Using minimum file size of 16 kilobytes.
Auto Mode
Command line used: /usr/local/bin/iozone -g 256k -n 16k -a
Output is in Kbytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 Kbytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.

noatime 选项的ext3文件系统，节选了16k和256k的性能指标，中间文件省略。

KB  reclen   write     rewrite    read        reread    read       write      read       rewrite     read       fwrite     frewrite   fread      freread

16       4  188610  486981  1068515  1775099  897109  483473  764288   693232   885274   321393   550950 1068515  1605256
16       8  326078  550950  2251544  2705381 1775099  616777 1068515   840903  1605256   486981   947789  730988  2251544
16     16  399920  700468  1985134  3225504 1985134  723111 1247244   723111  1605256   399920   730988 2045646  3225504

256       4  352068  627256  1766587  1814348 1132871  545654 1118707   873809  1112909   322851   602276 1652404  1766587
256       8  379842  735537  2266207  2665657 1855098  686620 1814348  1286217  1715775   380920   697322 2588541  2665657
256     16  425277  790209  3078337  3159869 2486631  775373 2392442  1600674  2463808   426120   780445 2783115  3123106   

noatime 选项的jfs文件系统，节选了16k和256k的性能指标，中间文件省略。  

16       4  192949  516994  1141196  2705381 1068515  550950  947789   791324  1068515   334198   640316 1320892  1985134
16       8  348064  594906  2600544  3225504 1985134  665724 1465076   934589  2045646   516994  1004538 2251544  3225504
16     16  388348  672395  3225504  4245865 3225504  755681 1605256   764288  2251544   371165   665724 2251544  3993221

256       4  371561  673696  2247235  2305128 1514860  621448 1504249  1137672  1504249   341324   646518 2205688  2247235
256       8  397563  770920  3159869  3207059 2350543  750445 2170027  1588832  2305128   390905   727070 3123106  2557711
256     16  426628  812329  3410808  3499745 2943325  792543 2812272  1778290  2903529   439193   800221 3410808  3511189

     从两个文件系统的表现来看ext3+noatime选项的性能还是略微优于jfs的性能，我们特别关注的是read 和reread性能，因为我们的文件系统中最高并发的还是read操作，所以这应该是我们最关心的数据之一。从这些表现上来看，最种我们选择了ext3，但是这次测试我们需要的是6.9T的文件系统。如果这个阀值大于8T，这个选择又会被改变了，如果reiser4被引入了linux kernel我想最终的结果也还会另有结论的。