Ext4 Workshop 2013 总结

作者:刘峥

2013年04月17日,Ext4 社区的开发者举行了一个讨论会。主要讨论目前 Ext4 文件系统中出现的问题及解决方法,以及后续的开发计划。本文章汇总了本次会议的内容。

在这次会议中,主要讨论了如下内容(每个话题中讨论的内容包括但不限于话题本身):

  1. write stall 问题
  2. 3.10 merge window 的相关情况
  3. 关于 Ext4 stable/long-term tree 的维护
  4. extent tree layout 修改
  5. bigalloc 特性的改进
  6. Online Fsck 特性的开发
  7. data=guarded 和文件系统延迟问题的优化
  8. 不同挂载参数的选择
  9. Ext4 针对不同设备的优化

与会人员:

  • Ted Ts'o (Ext4/JBD2 Maintainer, Google)
  • Jan Kara (EXT2/3/JBD Maintainer, SUSE)
  • Eric Sandeen (Red Hat)
  • Mingming Cao (Oracle)
  • Tao Ma (Tao Bao)
  • Lukas Cerner (Red Hat)
  • Zheng Liu (Tao Bao)
  • Darrick Wong (Oracle)
  • Mel Gorman (SUSE)
  • Daniel Phillips

1. write stall 问题

这一问题最初是由 MM 内核开发者 Mel Gorman 报告的,他在测试内存管理的补丁时,发现 Ext4 文件系统的交互响应比较差,延迟很高。通过观察发现是由于 do_get_write_access() 函数中会阻塞在 lock_buffer() 上,造成延迟较大。

Ted Ts'o 提出了两种解决方案:

1) 在调用 do_get_write_access() 时避免 lock_buffer;

2) 整体修改 JBD2,自己管理 buffer_head,从而降低延迟。

由于第二种方案太过复杂,短期内很难完成,所以目前打算先优化 do_get_write_access() 函数来降低延迟。同时,在刷新 metadata 时,通过加入 REQ_* 标记来避免优先级反转问题,提高响应速度。

 

2. 3.10 merge window 的相关情况

最近马上要开始新一轮的 merge window 了,所以 Ted 说明了一下目前的进展,他目前还在进行各种测试。Jan Kara 说他通过 xfstests 测试发现 data=journal 模式下第68项测试失败。Ted 则抱怨了一下 xfstests 没有支持 local group,造成每次测试都要手工指定测试项目。

Lukas 讨论了他关于优化 invalidatepage() 的补丁,Jan 表示会 review 代码。Ted 则说这个 merge window 可以考虑把 vfs 层的补丁先合并进来,下个 merge window 再解决 Ext4 专门的补丁。

Jan 则讨论了他关于优化 Ext4 writepage 路径的补丁,Ted 的建议是留到下一个 merge window 再合并。

 

3. 关于 Ext4 stable/long-term tree 的维护

Ted 对于 stable/long-term tree 的维护工作的态度是,目前他没有时间和精力来单独维护一个这样的 tree。目前,对于 Ext4 文件系统来说,如果需要使用较为稳定的版本,可以的选择是 linux stable tree。因为目前所有有意义的补丁会被抄送给 stable@vger.kernel.org,由 stable tree 对应的维护者来进行维护。当然,如果一些补丁不能够简单的直接打到 stable tree 上,则该补丁将不会包含在相应的 stable tree 中。

 

4. extent tree layout 修改

目前 Ext4 中 extent 存储的物理磁盘块的长度是 48 位,所以,可以将其扩展为 64 位以支持更大的磁盘分区。Ted 表示如果可以扩展到 64 位当然是最好的,但是这是一个长期的工作,目前还没有明确的需求需要搞这么大的文件系统。

目前 Ted 认为对于 Ext4 文件系统更为重要的事情是如下几个:

  • 解决 unwritten extent conversion 的问题,从而彻底实现 dioread_nolock;
  • 对 extent tree/map_blocks 函数进行重构;
  • mballoc 代码的重构和改进,包括 buddy bitmap 被很快回收的问题;

 

5. bigalloc 特性的改进

目前淘宝在使用 bigalloc 的过程中发现该特性还有一些不足,比如在使用 cluster (默认64k) 作为磁盘分配的单位时,对于小文件的存储,空间开销偏大。所以淘宝的想法是希望能够某几个 block group 按照 block size 来分配文件,剩下的 block group 按照 cluster size 来分配。这样可以尽量减少小文件对磁盘空间的占用。Ted 给出的建议是可以考虑指定一个参数,在格式化的时候,指定前面多少个 block group 通过 block size 来分配。这样做相对比较简单;另外一种更为简单的方法是将磁盘分成两个分区,分别按 block size 和 cluster size 来进行格式化,从而解决这一问题。

 

6. Online Fsck 特性的开发

这一需求也是淘宝目前遇到的实际问题。由于数据库等系统需要尽可能的在线提供服务,所以我们希望能够尽可能的缩短宕机后的启动时间。所以,如果可以实现 online fsck 的功能,则可以尽可能的缩短系统启动的时间,同时保证文件系统不被破坏。目前已知的可以进行 online fsck 的文件系统是 zfs, ffs, btrfs。Ted 给出的建议是可以考虑在分配磁盘块的时候在相应的 block group 上添加相应的标记,表明这个 block group 正在进行磁盘块的分配,在出现宕机后,这个 block group 的数据只进行读操作,所有写操作都会被映射到其他的 block group 中。这样可以尽可能的保证文件系统的一致性。

 

7. data=guarded 和文件系统延迟问题的优化

data=guarded 模式最早是 Chris Mason 针对 ext3 fsync 延迟过大提出的一种日志模式。但是后来由于 ext4 中引入延迟分配 (delalloc) 特性而没有再继续开发,也没有被合并进 upstream kernel。这次提出这个话题,主要是由于淘宝在部署 ext4 的过程中遇到了很多延迟问题。在讨论延迟问题的过程中,Ted 提出了一个长远的改进计划,即通过使用 extent status tree 在内存中进行磁盘块的分配,在 end_io 中再创建日志并修改元数据提交。这样可以极大地缩短日志的持有时间,从而尽可能的避免由于日志提交造成文件系统操作的延迟。同时 Ted 还建议减少延迟的方法是尽可能提前将文件预分配出来,同时尽量将文件的元信息保存在内存中。

 

8. 不同挂载参数的选择

这个话题主要是 Red Hat 和 SUSE 的开发者提出的,目的是减少 Ext4 测试环节的压力,同时由于 Linux 发行版陆续使用 Ext4 内核模块来处理 Ext2/3 文件系统,需要在内核中添加检查代码来确保 Ext2/3 文件系统在使用 Ext4 内核模块时的正确性。

其中比较重要的几个挂载参数是是:

  • indirect-based/extent-based 文件的支持;
  • async_journal_commit参数(该参数将被标记为危险,可能造成数据丢失);
  • data=journal 与 delalloc 的互斥问题

 

9. Ext4 针对不同设备的优化

这一话题主要是围绕目前文件系统开发的优化方向来进行讨论。由于 ARM 处理器在服务器领域的使用,文件系统即需要考虑高端硬件设备的优化,同时还要兼顾这类低端设备的优化。针对高端设备,文件系统可以多使用些资源(如内存资源)来获取更好的性能;同时针对 ARM 这类内存较小的设备,可以减小资源的使用,同时提供尽可能好的性能。

Ted 表示目前 Google 针对 e2fsck/mke2fs 工具是有一些优化的,并且已经放到了 upstream 的 e2fsprogs 中,但是并没有在内核代码中针对不同设备进行优化的想法。同时 Ted 表示目前可能更需要考虑针对 eMMC 设备的优化问题。

 

根据本次 Ext4 workshop,后续 Ext4 文件系统的开发主要包括:

  • extent tree 代码重构
  • map_blocks 函数代码重构
  • do_get_write_access() 优化,解决 write stall 问题(目前 Ted 已经将补丁发出并合并进ext4 dev 分支)
  • 使用 extent status tree 来优化磁盘块分配,减小延迟
  • 修改 extent tree layout 支持更大的磁盘
  • mballoc 代码的重构和优化

关于此前使用 extent status tree 实现 range locking 的问题。由于 Jan Kara 已经开始在 VFS 层实现一套通用的 range locking,因此目前与 Ted, Jan 讨论的结果是暂时先不在 Ext4 中单独实现一个 range locking 了。

未来一段时间,Ext4 的开发将主要集中在已有问题的解决,性能的调优和代码的重构上。暂时不会有新的供用户使用的新特性。

ext4在aio dio下的问题

[原写于2013年1月]

皓庭同学在给一台测试机做压力的时候出现了kernel panic:

<4>[ 223.202997] RIP: 0010:[] [] iput+0x69/0x70
......
<4>[ 223.210475] [] ext4_free_io_end+0x2d/0x40 [ext4]
<4>[ 223.210864] [] ext4_end_aio_dio_work+0xac/0xf0 [ext4]
<4>[ 223.211277] [] ? ext4_end_aio_dio_work+0x0/0xf0 [ext4]
<4>[ 223.211693] [] worker_thread+0x170/0x2a0
<4>[ 223.212033] [] ? autoremove_wake_function+0x0/0x40
<4>[ 223.212425] [] ? worker_thread+0x0/0x2a0
<4>[ 223.227238] [] kthread+0x96/0xa0
<4>[ 223.241935] [] child_rip+0xa/0x20
<4>[ 223.256518] [] ? kthread+0x0/0xa0
<4>[ 223.271085] [] ? child_rip+0x0/0x20

重现的环境和步骤都很简单:只要在redhat linux-2.6.32-279.14.1 kernel上进一个使用ext4的目录一跑:

stress --cpu 2 --io 2 --vm 1 --vm-bytes 128M --hdd 2 --timeout 1d

几分钟后就出现。
这个stress工具果然是神器。
由于重现步骤简单,我也没有太多需要绞尽脑汁的猜测和bug重现工作,就是加trace_printk一点一点调试,最后找到了原因:
stress测试工具是用DIRECT_IO发起的aio(异步IO)请求,在ext4里对于DIRECT_IO请求,都会用ext4_init_io_end初始化一个ext4_io_end_t结构,初始化时调用igrab对该inode里面的i_count就行递增;

struct inode *igrab(struct inode *inode)
{
spin_lock(&inode_lock);
if (!(inode->i_state & (I_FREEING|I_CLEAR|I_WILL_FREE)))
__iget(inode);
else {
/*
* Handle the case where s_op->clear_inode is not been
* called yet, and somebody is calling igrab
* while the inode is getting freed.
*/
printk("%s: %lx\n", __func__, inode->i_state);
inode = NULL;
}
spin_unlock(&inode_lock);
return inode;
}

这些aio结束后,会调用ext4_free_io_end进而调用iput把inode的i_count递减,等到i_count递减到0时,就用iput_final把该inode置为I_CLEAR,意思是该inode可被清除了(当内存不够的时候会把这种I_CLEAR的inode占的内存空间回收)。
但是,如果一个文件已经被rm了,即已经调用了generic_delete_inode,那么inode就已经置上了I_FREEING,此时再调用igrab时,由于第一个判断无效,inode里的i_count就不会被加1了,i_count会一直保持0!等到aio结束后,iput被调用了多次,第一次触发iput_final把inode置上I_CLEAR,第二次就坏了,触发BUG_ON

void iput(struct inode *inode)
{
if (inode) {
BUG_ON(inode->i_state == I_CLEAR);

if (atomic_dec_and_lock(&inode->i_count, &inode_lock))
iput_final(inode);
}
}

因为一般对同一个inode,调了iput_final就不能再调iput了,因为你已经final了、没了。
说来说去,就是igrab似乎不该做那个判断,或者,干脆不要用igrab,用别的计数方式。翻了一下upstream,得,又已经被fix了,commit f7ad6d2e9201a6e1c9ee6530a291452eb695feb8, Ted两年前就已经fix了,抛弃了igrab改为自己管理计数。这个fix backport到rhel-2.6.32-279 kernel还需要一些修改,好在有文卿帮我review代码。

还要感谢皓庭同学帮忙找到了这么快速的重现方法,以及余峰老哥推荐的stress这个生猛工具。

CLSF2012讨论会纪要(二)

[原写于2012年10月]

第二天,来自淘宝的刘峥介绍一年来ext4文件系统的开发进展。
ext4的bigalloc,增大分配单位,减少元数据,加快硬盘检查和创建大文件的速度。meta data checksum,让文件系统的错误更早更快的暴露出来,有利于数据安全和文件系统本身的稳定,但是打开checksum会造成大约20%的性能损失,这个就看用户的选择了。inline data,将小文件或目录(小于4K)的数据放入inode之中,根据统计,ext4上大约70%的目录都在100字节以内,所以这个特性对小目录众多的应用有较好的性能提升。
NO_HIDE_STALE,当用户用fallocate分配了一个大文件的磁盘空间以后,一旦他开始随机写,由于extent会从UNWRITTEN变成全零,大的extent会被切成很多小的extent,元数据会大量增加,journal会频繁写硬盘,这样性能就大大下降了;现在有了NO_HIDE_STALE,用户可以通过ioctl指定:我在从大文件里读一段内容之前一定会先写入正确的内容,没写过的部分我不会去读的,这样,不再又extent的分裂,也没有了频繁的写journal,性能就得到了保证。这是刘峥在跟踪TFS在使用ext4后性能退化的问题时发现的改进方法。这一方法对像Oracle或IBM的DB2这样的数据库系统也是有用的。
status extent tree,将硬盘上extent tree的信息保留在内存里,这样查找和空间判断都变得简洁了。这一工作还在进行,相关patch还没有merge到ext4里。
做direct io的覆盖写时不拿i_mutex,能减少大文件多线程写时的锁竞争,对于使用SSD的数据库系统来说效果非常明显。
ext4开始支持带meta_bg的在线resize。

来自fusionio的李少华介绍了这一年来在快速存储设备上遇到的性能瓶颈及相应的对linux block层的改进。
虽然fusionio的卡很贵,但是仍有不差钱的公司采用多块fusionio卡做raid的方案(应该是金融行业),之前kernel软raid的很多代码和配置在高速PCIE设备上遇到了问题,比如机械硬盘做raid时默认stripe是512K,但是在fusionio的raid上这一size过大,不能发挥SSD随机读写的高IOPS特性,所以应该选小的stripe,当然,也不能太小,太小会造成request被分割到不同的设备上。少华在测试中发现的理想stripe大小是8K或16K。
少华提醒:SSD读是不影响寿命的,但是写会,所以要尽可能的减少对SSD的写(这大概是为什么很多人用SSD盘来做系统盘,存放可执行文件、公共库等只需读的文件);在SSD快满时,写操作的throughput会下降(主要是因为SSD自己在做gc),而适时的做trim操作(告诉SSD的firmware某块区域不再需要被使用)可以避免这个问题。
coly问:trim以后的那片区域是能保证read全零吗?
少华:没有这个保证
少华还提到,由于RAID是将多个设备聚合成一个,这个新设备只有一个flusher进程来写脏页,性能不够。吴峰光说将来有计划实现一个device多个flusher。
大家还讨论到了fusionio(也包括其它一些SSD厂商)的PCIE-flash卡支持atomic write,由firmware加硬件来保证一个写请求要么成功,要么没发生。这是个杀手级的功能,文件系统为了实现写事务,都是用的journal,不仅代码多而复杂,且对性能也有损失。如果firmware支持原子写,那文件系统完全可以把journal拿掉,专心至致的优化磁盘布局了。
其实固态存储对文件系统的冲击还不止这些,比如,SSD里其实有map来记录逻辑存储地址到实际硬件地址的信息(就是FTL,flash translate layer),而文件系统也有记录文件偏移到逻辑存储地址的信息,显然有点重复了,所以fusionio提出了directfs,一个文件一旦创建就给1T的大小,但是这个1T没有任何对应的物理地址,直到用户开始在文件里写了,才利用SSD里的那个map直接把文件偏移映射到物理存储地址,简洁高效,还带点前卫。这是不是文件系统发展的一个方向?

来自IBM的Zhiyong Wu介绍了最近他们在做的在vfs层统计热数据的工作。他们会在vfs层采集数据被读取的频率,以此算出数据的“温度”是热还是冷,并提供给文件系统层去做数据迁移。统计粒度是1MB。Coly认为统计这个对互联网企业来说最大的用处,不是数据迁移,而是找出应用的bug(运转不好的应用会多次读取热数据)。大家觉得统计所有inode的信息太费内存了,最后提供接口,可以统计某几个inode的信息。
我看介绍里有统计热数据的top200,便问这个排序是在什么时候做的,Zhiyong回答说是每次发生io时都会排序。大家觉得这显然太费了,我建议不在内核里排序,直接把数据和它们的访问频率暴露出来,运维人员一个sort -k2命令就可以自己搞定排序的事情 🙂

接下来是redhat的Asias He介绍他在virtio里做的vhost-blk。有了host-blk,从guest os来的io请求会被直接map成host上的bio(以前这些guest os来的io会变成QEMU的针对host os的read和write系统调用,相当于走了两遍kernel的io路径)。大家讨论了各个公司的虚拟化方案,现在最热的云计算说白了就是虚拟机集群,xen是企业级用的最多的,一些互联网公司在尝试container的方案以获得最优的性能(如openvz、lxc),而KVM是redhat主推的(在rhel6里已经把kvm设为默认虚拟机,不再支持xen),原因是kvm毕竟是社区比较认可的虚拟化方案,而lxc等container方案安全性不够。

最后由memblaze的LuXiangFeng做业界SDD存储的报告。
memblaze是类似fusionio的国内创业公司,他们对PCIE的SSD设备做了很多软件方面的开发,提供了多种接口,既可以像磁盘一样线性访问,也可以像key/value存储那样直接put/get(这个对互联网应用挺方便的),还可以做raw device操作(比如应用直接去并行操作SSD上的不同channel,或者应用自己去做gc)。对SSD做单线程的读写是无法发挥SSD的高iops特性的,应用应该加大io并行度——或者通过启动多线程读写,或者通过aio来增加iodepth。

clsf 2012
全体参会人员合影

结语:感谢 支付宝 赞助此次CLSF讨论会

CLSF 2012讨论会纪要(一)

[原写于2012年10月]

10月11日到12日两天在EMC北京办公室参加了CLSF 2012 讨论会。简要记录之,难免碎片,如有错误,欢迎拍砖。
第一天首先是南大富士通的缪勰介绍btrfs这一年的新进展。
btrfs已经具有了在线修改RAID的stripper大小、自动修复RAID1的坏盘等功能,且将meta block的size变为可调(上限64K),这样btree就矮了很多(因为node大了),在删除大文件时seek过程变少了,删除速度更快。
ext4如果发现io error会将文件系统置位read-only,而btrfs以前是没有这个能力的,今年才开始学ext4,加上了坏盘时置read-only的功能。
btrfs还增加了subvolume的quota功能,增加了send/receive对文件系统进行整体备份和恢复(这个备份是备份btrfs的那棵btree,就免得全盘备份了,但是大家觉得,好像这个功能没有太大的用户市场)
还有一些未来的优化工作:
btrfs提供强大的snapshot功能,但是如果一个文件做了太多的snapshot,那么一个node可能有很多snapshot point指向它,如果现在要对这一个node进行操作(btrfs是广泛利用COW的,所以即使是覆盖写,也要copy出来一份新的),那么还需要把多个snapshot指下来的point都改为指向新node,反向查找很费力,以后计划加入了一个中间的ref,snapshot point都指向这个ref,ref再指向node,那么如果node变了位置,只要把ref改一下就行了,不用改所有的snapshot point。
btrfs未来也会采用buddy system来管理free space(类似ext4),以减少磁盘碎片。
线下讨论我向缪勰请教了一些btrfs的问题,才知道btrfs里文件的inode、inode ref、extent等元数据是混合放在一棵fs tree里的,所以对一个文件的查找或对某文件内容的查找都是在一棵btree里,虽然btrfs会尽可能的把一个文件的相关元数据往一个node里放,但是也不保证在插入新pair时node分裂会把元数据给隔开。btrfs在性能上确实还有很多工作要做。

clsf 2012
大家在休息时间各自讨论

来自Oracle的刘博同学主要介绍了一下一年来他在文件系统性能优化方面积累的一些经验和工具。
Chris Mason的seekwatcher是跟踪io性能的好工具,但是它只能处理单硬盘的io数据,所以Chris现在打算开发更先进的iowatcher,能够处理多块硬盘,还能看到io的latency和cpu状态,提供的信息更综合。比如,btrfs在写时throughput还行,但是latency较大(写很多小文件时尤其明显),所以怎么观察和优化这些latency迫切需要强大工具的支持。
刘博同学还提到了ftrace,而我们推荐了朱辉开发的kgtp,可以实时在线调试(很方便我们这些经常需要查线上kernel bug的苦逼码农)且延时很小。但是kgtp一直没有进upstream,淘宝kernel自己backport了这部分代码。
Asias He同学问我们测文件系统用哪些工具,其实我们组根本连一个QE都没有(不能跟redhat、SUSE、Oracle这些做发行版的公司比),文件系统都是靠开发人员自己测(自己吃自己的狗粮,也挺好),我们把iozone、fsmark、xfstest、postmark等一堆开源测试工具用脚本攒在一起(“要你命三千”),对着文件系统一顿高压力的狂轰乱炸几天几夜,如果没有panic、也没有“block 120 seconds“,就算是过了。当然,功能测试还需要开发自己另外写程序来模拟。

接下来是Oracle的Jeff Liu介绍一年来xfs的开发进展。
在各大公司的运维人员和DBA中,都流传着“xfs文件系统对大文件的性能最好”的传说。但毕竟只是传说,coly给出了一个故事,还是比较有说服力的:ext4文件系统刚开发出来的时候(好像是2006年前后),很多评测结果都好于xfs(包括大文件),那时xfs是输在了journal的性能上;两三年后,xfs改进了journal的性能,评测结果超过了ext4;然后,ext4开始学习xfs的部分优化方法,性能又超过了xfs....所以,实际在upstream里,这两个文件系统的性能是在互相追赶,并没有一个权威的标准说明谁比谁更好或者更不好。
ext4和xfs对文件都是使用btree,从设计的角度来谁也没有压倒性的优势,所以关键还看细节处的优化。所以我不完全赞同“架构决定性能”,架构是决定了性能的“天花板”,但是最后能不能到达这个天花板,还看具体开发人员的努力。我觉得架构师们都是非常聪明的人,而好的架构往往是高度相似的,所以靠架构领先来取得压倒性优势并不常见(大家看看现在各大互联网公司的所谓“分布式存储”,是不是架构都长得很相似?架构都相似了,性能也不会差特别大),常见的还是靠在细节处修bug、找性能瓶颈的默默无闻的码农来一点一点的优化,最终靠高稳定、高性能、高便捷来赢得用户。所以,传说中的“xfs性能好于ext4”值得商榷。
xfs最初是从SGI UNIX里移植到linux上来的,当时linux的vfs层做的不好,所以移植过来的xfs代码也包括了一些本来该vfs做的事情,所以linux里的xfs代码非常庞大(10万行),维护是个很大的负担。所以xfs最近的工作都集中在精简代码上,很多patch都是在做删代码的工作。一个很典型的例子:xfs的writeback函数调用路径特别深,linux kernel提供的4K大小的stack根本不够用,于是想出了一个神办法,就是在函数调用路径的中间停下来,把剩下的调用工作放入work queue,让剩下的操作稍后由延时任务自己来完成。这样stack才不会被撑爆。
来自fusionio的李少华:我在测试中发现work queue的扩展性很差,你如果太频繁的往里面放东西,性能是会急剧退化的,而且把work放入queue的CPU和以后将执行此work的CPU很可能不是同一个,这将影响CPU的cache。
Jeff Liu:这些锁竞争和CPU级的速度损失,跟IO的性能相比,不算什么的,一次写盘或读盘,几个毫秒都过去了,省那几百个微秒并不紧要

然后是腾讯的冯小天介绍腾讯内核组的工作。
腾讯的新内核是基于mainline的2.6.32内核,虚拟机用xen,而目前的云平台是用的container。基于mainline带来了很多bug,一路踩了不少雷,要是一开始基于rhel6的2.6.32内核就好了(看来我们是幸运的)。小天在推广新内核上也遇到很多困难:业务方不肯升级OS,甚至重启机器都不愿意,尤其是208天的那个bug搞得腾讯内核组非常郁闷。未来,准备利用腾讯上SSD盘的机会把ext4也推上线。
Coly提到了淘宝CDN使用的SSD盘坏得很少,其实比机械盘耐用。

clsf 2012
中间穿蓝色衣服的是来自腾讯的冯小天

淘宝的余峰介绍了淘宝在使用mysql中对linux文件系统和存储层提出了新的要求。
目前mysql使用的innodb引擎会造成短时的大量IO,性能会有抖动,考虑换成levelDB的LSM引擎。现在SSD的出现让pc server的IO能力变得过剩,通过在一台服务器上启动多个mysql实例来更加充分的利用IO资源。目前SSD卡似乎没有接口看“使用寿命还剩多少”,等出了问题再换盘就麻烦了,来自memblaze的唐志波回答说,一般SSD写10 P的数据(或者使用3年)就会有较多错误出现,而厂家一般是到3年就要给更换的。

最后是EMC的Xuezhao Liu介绍lustre client。最近他们和whamcloud合作,计划把lustre的client推到kernel code里,Peng Tao今年4月份参加LSF的时候提出了这件事,社区表示欢迎,当然,前提是清理代码让其符合kernel code style。推进的工作除了清理代码、整理格式,还要将client部分从lustre代码中剥离出来。
问:lunstre client代码有多少?
答:里面光是通信方面就有三万行代码,总共十万行。
大家惊了。一次往kernel里进十万行代码,这还是相当不容易的。