存储系统性能影响因素(1)---文件系统
2018-03-14 14:36
323 查看
文件系统的inode分配及数量、文件搜索方式如HTree、文件读写方式如COW或WAL (write-ahead-log)会影响存储性能。Btrfs文件系统就是采用了CoW以及Transaction的机制保证了数据的一致性。
-------------------------------------------------------------------------------------------------------------------------------------------
COW 在某些情况下可以提升性能,比如说如果对元数据的更新是随机的,因为不在原来的位置就行write, 随机的block 重新分配到了一段连续的元数据空间,这样在事务进行刷新写的时候,一堆顺序的block 可能会被批量写到磁盘上去,这点对性能的提升和Ext4 日志文件系统中日志都是顺序写有点像。但是COW也会导致文件数据分配到磁盘的各个位置,导致额外的seek 比较严重,比如COW的文件系统非常不适合KVM的image文件,一个文件的extent 可以达到上万个,对性能损失可想而言。
另外和日志文件系统相比,COW的文件系统对于保证文件系统的一致性保护更彻底,COW的特点是没有Replay 的动作的,如果发生掉电或者系统宕机,重启机器,文件系统直接保持在旧的状态。但是日志文件系统,比如说Ext4,掉电重启之后,需要做Log Replay, 但是在做Log Replay的过程中如果发生二次掉电(虽然很少见),这时候是没有保护的。可能会导致文件系统不一致的现象发生。
-------------------------------------------------------------------------------------------------------------------------------------------
很多老的文件系统都不支持COW,比如FAT家族都不支持,但主流的文件系统都多多少少支持一点COW,比如BTRFS,NTFS等。其实COW对于用户数据来说,并不是特别重要,多数文件系统也不能承诺掉电以后究竟能恢复多少数据(我印象里只有tffs能做到恢复)。COW的好处是对文件系统元数据的保护,元数据包括文件名、文件大小、属性、路径结构等等,这些数据如果损坏,轻则丢失文件,重则分区完蛋。比如在FAT分区上,如果在大规模删除、复制文件的时候突然断电,文件夹结构可能就有破坏的风险,而如果支持COW的话,文件系统能很容易回滚数据到前一个状态(虽然也会丢失文件),保证文件系统自身结构稳定。
------------------------------------------------------------------------------------------------------------------------------------------
我们一般会将覆盖写的系统,比如WAL (write-ahead-log)拿来和COW(copy on write)相比,日志型文件系统很多都是WAL的形式,通过journal来保证一致性。而当下较热的btrfs则是通过COW的形式保证一致性。
首先WAL既然不是COW,所以他写文件的方式是覆盖写。如果在写入过程中发生故障,就会产生非常窘迫的情况: 重启以后那次写入到底有没有成功就变成了未解之谜。并且如果我们既没有备份写入前的数据,也没有预先持久化应该写入的数据,那么就既无法roll-back,也无法redo。数据这时候相当于被损坏掉了。能不能修复是后话。
所以在严谨的分布式存储系统Ceph中,如果使用了ext4/zfs等WAL形式的文件系统作为本地文件系统,那么在数据真正刷入硬盘指定位置之前,都会提前将事务和数据一起持久化到硬盘上,然后执行刷入,如果刷入为成功,就会从日志中提取buffer数据,然后replay当时的写入事务。在这种情况下,为了保证数据一致性,我们牺牲了写入时的效率,将一次写入变成了两次写入,HDD的写速度直接下降一半。
但是如果使用了btrfs这种COW的文件系统,就不会有两次写入的问题了,其他同学把COW讲的非常清晰,COW不是覆盖写,所以只要写入失败,文件系统自然而然就会回退到前一个状态,那个状态下数据是一致的,就不用担心数据损坏的问题。
其次是备份的时候,相信很多人都被备份数据所占用的空间而烦恼,甚至会定期拿360把windows自动备份给删了...另外比如ios系统中,不同应用之间的数据传递是拷贝的模式,那么很现实的问题就是,如果拿**云下的电影用**影音打开,不用多少时间ios的空余空间就会被使用殆尽。这就是非COW的文件系统的缺陷。
在COW系统中,备份/复制文件其实只是将目标文件的元数据部分的数据指针指向了源文件的那些数据段,所以拷贝文件的时间几乎可以忽略不计。当要对拷贝后的文件执行写入的时候,只需要将写入的数据放到新开辟的硬盘空间中即可。总之拿COW的文件系统做一键还原或者大文件应用间共享是非常方便的。
最后,碎片话问题大家都有,但是COW文件系统相对严重。一个好的在线碎片整理系统是COW文件系统保证自己效率的必要手段。另外,用SSD也能一定程度减轻碎片化问题。
-------------------------------------------------------------------------------------------------------------------------------------------
COW 在某些情况下可以提升性能,比如说如果对元数据的更新是随机的,因为不在原来的位置就行write, 随机的block 重新分配到了一段连续的元数据空间,这样在事务进行刷新写的时候,一堆顺序的block 可能会被批量写到磁盘上去,这点对性能的提升和Ext4 日志文件系统中日志都是顺序写有点像。但是COW也会导致文件数据分配到磁盘的各个位置,导致额外的seek 比较严重,比如COW的文件系统非常不适合KVM的image文件,一个文件的extent 可以达到上万个,对性能损失可想而言。
另外和日志文件系统相比,COW的文件系统对于保证文件系统的一致性保护更彻底,COW的特点是没有Replay 的动作的,如果发生掉电或者系统宕机,重启机器,文件系统直接保持在旧的状态。但是日志文件系统,比如说Ext4,掉电重启之后,需要做Log Replay, 但是在做Log Replay的过程中如果发生二次掉电(虽然很少见),这时候是没有保护的。可能会导致文件系统不一致的现象发生。
-------------------------------------------------------------------------------------------------------------------------------------------
很多老的文件系统都不支持COW,比如FAT家族都不支持,但主流的文件系统都多多少少支持一点COW,比如BTRFS,NTFS等。其实COW对于用户数据来说,并不是特别重要,多数文件系统也不能承诺掉电以后究竟能恢复多少数据(我印象里只有tffs能做到恢复)。COW的好处是对文件系统元数据的保护,元数据包括文件名、文件大小、属性、路径结构等等,这些数据如果损坏,轻则丢失文件,重则分区完蛋。比如在FAT分区上,如果在大规模删除、复制文件的时候突然断电,文件夹结构可能就有破坏的风险,而如果支持COW的话,文件系统能很容易回滚数据到前一个状态(虽然也会丢失文件),保证文件系统自身结构稳定。
------------------------------------------------------------------------------------------------------------------------------------------
我们一般会将覆盖写的系统,比如WAL (write-ahead-log)拿来和COW(copy on write)相比,日志型文件系统很多都是WAL的形式,通过journal来保证一致性。而当下较热的btrfs则是通过COW的形式保证一致性。
首先WAL既然不是COW,所以他写文件的方式是覆盖写。如果在写入过程中发生故障,就会产生非常窘迫的情况: 重启以后那次写入到底有没有成功就变成了未解之谜。并且如果我们既没有备份写入前的数据,也没有预先持久化应该写入的数据,那么就既无法roll-back,也无法redo。数据这时候相当于被损坏掉了。能不能修复是后话。
所以在严谨的分布式存储系统Ceph中,如果使用了ext4/zfs等WAL形式的文件系统作为本地文件系统,那么在数据真正刷入硬盘指定位置之前,都会提前将事务和数据一起持久化到硬盘上,然后执行刷入,如果刷入为成功,就会从日志中提取buffer数据,然后replay当时的写入事务。在这种情况下,为了保证数据一致性,我们牺牲了写入时的效率,将一次写入变成了两次写入,HDD的写速度直接下降一半。
但是如果使用了btrfs这种COW的文件系统,就不会有两次写入的问题了,其他同学把COW讲的非常清晰,COW不是覆盖写,所以只要写入失败,文件系统自然而然就会回退到前一个状态,那个状态下数据是一致的,就不用担心数据损坏的问题。
其次是备份的时候,相信很多人都被备份数据所占用的空间而烦恼,甚至会定期拿360把windows自动备份给删了...另外比如ios系统中,不同应用之间的数据传递是拷贝的模式,那么很现实的问题就是,如果拿**云下的电影用**影音打开,不用多少时间ios的空余空间就会被使用殆尽。这就是非COW的文件系统的缺陷。
在COW系统中,备份/复制文件其实只是将目标文件的元数据部分的数据指针指向了源文件的那些数据段,所以拷贝文件的时间几乎可以忽略不计。当要对拷贝后的文件执行写入的时候,只需要将写入的数据放到新开辟的硬盘空间中即可。总之拿COW的文件系统做一键还原或者大文件应用间共享是非常方便的。
最后,碎片话问题大家都有,但是COW文件系统相对严重。一个好的在线碎片整理系统是COW文件系统保证自己效率的必要手段。另外,用SSD也能一定程度减轻碎片化问题。
相关文章推荐
- 存储系统性能影响因素(1)---文件系统-----freenas的ZFS和RAID技术
- 文件系统那些事-第3篇 影响文件系统性能的关键因素:存储块分配和布局策略
- 文件系统那些事-第3篇 影响文件系统性能的关键因素:存储块分配和布局策略
- mysql本身对性能影响的因素存储引擎、数据库配置、数据库表结构及sql语句
- 文件系统对性能的影响
- J2EE系统中影响性能的一些因素
- 性能指标之资源指标-磁盘-评估不同存储保护方式对系统性能影响
- J2EE系统中影响性能的一些因素
- MongoDB的GridFS与文件系统在小文件存储的读取性能对比
- J2EE系统中影响性能的一些因素
- MongoDB的GridFS与文件系统在小文件存储的读取性能对
- 存储:F2FS文件系统读写性能良好
- J2EE系统中影响性能的一些因素
- 影响推荐系统性能的因素
- ceph存储 centos文件系统变为只读的解决处理
- Linux下的文件系统分类(以存储介质)
- 架构设计:系统存储(7)——MySQL数据库性能优化(3)
- Linux上几个可以影响到服务器并发处理性能的系统参数
- 开启 NFS 文件系统提升 Vagrant 共享目录的性能
- GlusterFS分布式集群文件系统安装、配置及性能测试