深入浅出文件系统中的日志系统功能

1.日志系统出现的背景

日志系统出现在20世纪末。最早的日志文件系统出现在1990年IBM的JFS(journal
file system)上。1994年,为了更好地支持高性能,SilliconGraphics引进了XFS。从20011年开始,linux系统中就开始支持ext3fs。到了今天,ext4fs、Reiser4、ceph等文件系统都支持了日志系统。

2.日志系统的功能

日志文件系统的功能主要是为了提高文件系统的一致性和性能。

2.1一致性

通过日志系统记录写操作,避免异常关机、掉电等造成文件系统中元数据和文件数据的不一致,文件系统重启后能通过重放之前未完成的操作来实现一致性。

2.1性能

在当代的文件系统设计中,利用快速的日志设备来提高文件写操作的速度,比如SSD以及一些非易失性内存,都可以用来当作日志设备。此外,还可以在日志系统层次进行写合并等优化。

3.日志系统的原理

3.1日志系统避免文件系统崩溃的原理

在系统异常掉电、关机或者重启的情况下,很可能出现存储设备上
的用户文件数据和文件索引、记录等元数据不一致的情况。针对这一问题,传统的Linux系统通过在开机时用fsck命令来检查元数据和用户文件数据是否一致。如果一致,可以认为文件系统完整无损;否则,需要定位是哪一块设备造成这一现象,随之进行恢复。如果fsck也不能恢复,可能需要进入单用户模式手动进行恢复。有了日志系统之后,写入的raw
data先到了独立于文件系统的日志设备或者资源上,只有当文件data写入到了文件系统磁盘或者日志设备之后,文件系统最后才会把raw
data写入到文件系统磁盘里面去。这样就能保证文件系统对应的磁盘里的raw
data和data的一致性。

根据写文件数据和元数据的先后顺序,日志文件系统可以分为下面几种:


Type


Wring
file data to Log


Writing
raw data to Log


comments


Write-back


Second
step:

N,
to disk


First
step: Y


May
crash when system crash before writing to disk


Ordered


First
step: N, to
disk


Second
step: Y


Keep
coherence


Data


Second
step: Y


Firste
step: Y


Affect
performance

日志系统上会记录一条条待提交的写操作,根据每次提交记录的数目和日志设备是否满的状况,又可以分成下面几种方式:


Type


Sub-type


Comments


One
record per commit


Quickly
sync between log and disk, worse performance


Several
records per commit


Commit
when log is full


Slowly
sync between log and disk, better performance


Commit
when log isn‘t full

由于日志设备上记录的数据是非易失性的,系统重启后文件系统的初始化过程中会把日志设备上记录的、尚未写到文件系统盘上的raw
data乃至文件数据写到文件系统盘。这个过程就像把之前记录的写操作一个个复现,也叫做重放或者重演。

3.2日志文件系统加速文件写操作的原理

日志对写操作的优化来自于日志设备较之于普通文件系统磁盘写操作快得多的速度。两种设备写操作的速度差异越大,日志系统对写操作的性能提升就越多。和不用快速设备做log
device的文件系统相比,每一次IO写操作,这种方案能节省的时间是之前一次文件系统盘写的时间减去一次log
device写的时间。

当文件系统把元数据乃至文件数据写到日志设备后,就可以向上级返回写操作完成。此时,虽然数据还没有真正落到文件系统盘,但是后台会有线程或者类似机制把log
device上的数据自动提交到文件系统盘上去。因此,日志文件系统只是尽快迅速地把写请求返回,以提高性能。代价就是元数据乃至文件数据在日志设备上额外的写操作。

4.日志系统举例

4.1
ZFS

ZFS文件系统中的ZIL层对日志功能的支持非常灵活,既提供了CLI来指定用作日志功能的设备,又提供了参数来配置同步策略。ZFS中关于日志功能的最主要的操作有三个:

zil_commit 往日志设备添加记录

当写操作创建好transaction并把它放到目标设备的操作队列之后,会直接调用zil_commit操作,把log
record写到日志设备上去,也就是把内存中的metadata乃至data写到ZIL的日志设备上去。

zil_sync 从日志设备删除记录

当目标设备上的某个transaction完成之后,会通过zil_sync从ZIL
log device上找到transaction
number一致的log
record,把它从日志设备中删除。

zil_replay 重启时重放ZIL
log

当ZFS文件系统重新起来之后,如果发现ZIL
log device上还有没有log
record,就把它zil_sync到磁盘。

由于ZIL的log
device也是基于ZFS里的逻辑设备,因此理论上它也能够实现对log
device上数据的checksum乃至压缩。此外,它还支持重复写操作的合并。

4.2
ext3fs

Ext3区别于ext2的最主要特性就在于引进了日志功能,嫩够记录metadata,因此提供了更好的一致性。当然,由于ext3的日志设备也是普通的磁盘设备,对性能的影响很大。

4.3
ext4fs

ext4文件系统通过在磁盘上保留一段小的连续区域(默认128MB)作为JBD。被提交的数据一份记录也被写到日志。一旦数据事务完全写到磁盘,将其从JBD中刷出。这样保证日志在擦除提交记录前将事务写到它们在磁盘上的最终位置(可能包含大量的寻道或者大量的读-写-擦除)。从一致性方面考虑,Ext4默认直接将文件系统元数据写到日志,而没有同时写文件数据到JBD2,因而不能提供最强的文件数据块的一致性。ext4fs日志文件在文件系统中是普通文件,通常隐藏不可见。日志文件消耗完整的块组,通过mke2fs可以将日志文件放在磁盘的中间。

此外,在ext3fs文件系统日志机制的基础上,ext4fs添加了对日志内容的checksum,这样对数据的一致性和正确性有了更多更及时的保护。

4.4
ReiserFS

ReiserFS 是从一开始就按照记录日志的意图而开发的日志文件系统。ReiserFS 于 2001 年被引进到主流 2.4 内核(Linux 采用的第一个日志文件系统)。其默认的日志记录方法为预定,且支持以在线调整大小的方式扩展文件系统。

4.5
ceph

ceph文件系统日志基于ceph
OSD的关键组成部分,能提高存储系统的一致性和性能。ceph文件系统里能够指定同步日志和文件系统盘的时间间隔,当间隔时间到,ceph
OSD
daemon会停止写操作,把所有日志系统上记录的写操作重放到磁盘上去。这样就保证了文件系统的一致性。此外,Ceph能将小的随机IO顺序地写入日志,让后端文件系统有更多时间来合并IO,提升系统的突发负载能力。美中不足的是,这可能带来剧烈的性能抖动,表现为一段时间内的高速写入,而之后一段时间内没有任何写入直至直至日志设备又有空闲空间能够启用。

4.6
GFS

GFS是Google设计的一个可扩展的分布式文件系统。GFS日志系统包含了对元数据所作的修改的历史记录。它作为逻辑时间线定义了并发操作的执行顺序。文件、块以及它们的版本号都由它们被创建时的逻辑时间而唯一地、永久地被标识。由于GFS是分布式文件系统,所以只有操作日志复制到数个远程的机器上,并且确实写到本地和远程的磁盘上之后才回答用户的请求。

在一致性方面,GFS
Master节点同样可以用操作日志来恢复它的文件系统的状态。但为了将启动时间减至最小,日志就必须要比较小。每当日志的长度增长到超过一定的规模后,master就要检查它的状态,它可以从本地磁盘装入最近的检查点来恢复状态。

4.7
JFS

(
JOURNAL FILE
SYSTEM)一种字节级日志文件系统,借鉴了数据库保护系统的技术,以日志的形式记录文件的变化。JFS通过记录文件结构而不是数据本身的变化来保证数据的完整性。这种方式可以确保在任何时刻都能维护数据的可访问性。

需要注意的是:JFS只记录元数据上的操作,因此,重放这些日志只能恢复文件系统中结构关系和资源分配状态的一致性。它没有记录文件数据,也没有将这些数据恢复到一致状态。因此,恢复后某些文件数据可能丢失或失效,对数据一致性有关键性需求的用户应该使用同步I/O。

如果媒介出错,日志记录不是特别有效。特别地,在将日志或元数据写入磁盘的期间发生的I/O错误,意味着在系统崩溃后,要将文件系统恢复到一致状态,需要耗时并且有可能强加的全面完整性检查。

JFS日志记录的语义如下:当涉及元数据更改的文件系统操作--例如,unlink()--返回成功执行的返回码时,操作的结果已经提交到文件系统,即使系统崩溃了也可以发现。例如,一旦成功删除了文件,即使系统崩溃然后重启,它仍然是删除的并且不会再重新出现。

与其它日志文件系统相比,JFS没有提供写合并,在性能上处于劣势。其它日志文件系统,如Veritas
VxFS 和Transarc
Episode,使用不同的日志风格并且缓慢地将日志数据写入磁盘。在执行多个并行操作的服务器环境中,通过将多个同步写操作组合成单一写操作的组提交来减少这种性能损失。JFS日志记录风格随着时间推移而得到不断改进,现在提供了异步日志记录,异步日志记录提高了文件系统的性能。

4.8
XFS

XFS一种高性能的日志文件系统,最早于1993年,由Silicon
Graphics为他们的IRIX操作系统而开发,是IRIX
5.3版的默认文件系统。2000年5月,Silicon
Graphics以GNU通用公共许可证发布这套系统的源代码,之后被移植到Linux内核上。XFS特别擅长处理大文件,同时提供平滑的数据传输。

当文件系统更新时,元数据会在实际的磁盘块被更新之前顺序写入日志。XFS的日志被保存在磁盘块的循环缓冲区上,不会被正常的文件系统操作影响。XFS日志大小的上限是64k个块和128MB中的较大值,下限取决于已存在的文件系统和目录的块的大小。在外置设备上部署日志会浪费超过最大日志大小的空间。XFS日志也可以被存在文件系统的数据区(称为内置日志),或者一个额外的设备上(以减少磁盘操作)。XFS的日志保存的是在更高层次上描述已进行的操作的“逻辑”实体。相比之下,“物理”日志存储每次事务中被修改的块。为了保证性能,日志的更新是异步进行的

5.日志文件系统发展想法

现在nvme、3D-Xpoint等新型技术和硬件的出现和推广,既对文件系统中日志系统的设计提出了心的要求和挑战,比如如何充分利用新技术和硬件的特性,更好地日志系统的组织结构、工作机制,以充分提高性能;同时,又为新的日志系统的设计提供了更多的日志设备的硬件选择空间。

6.参考文档和引用链接

1.http://blog.sina.com.cn/s/blog_701bb13a0100n9k6.html

2.http://www.cnblogs.com/vamei/p/3506566.html

3.http://blog.csdn.net/lzw06061139/article/details/51169117

4.http://baike.baidu.com/link?url=TzCHwaidRBo8WzT772s7zeiqf4imd40zuZoMmOtVBuDtRFDmjDjZzF60bJPXWggeUy6OGGKVl9NGqDIWnmkJXYhfPdwXJ8ezMaI8LMh7DBS

5.http://blog.sina.com.cn/s/blog_573860a90101032h.html

6.http://blog.chinaunix.net/uid-25052030-id-2236173.html

7.http://www.cnblogs.com/wuchanming/p/3737761.html

8.http://baike.baidu.com/link?url=vZxSHOgtyXlCtkTtQyoiCZoTnsZvyMHjC2G_JLK8hTWnaP_8K-yQBndcLlUtIZTW260sumi2AOwm8_GUIo0WI_

9.http://baike.baidu.com/view/1494218.htm

时间: 2024-10-22 14:41:20

深入浅出文件系统中的日志系统功能的相关文章

Linux中的日志分析及管理

日志文件对于诊断和解决系统中的问题很有帮助,因为在Linux系统中运行的程序通常会把系统消息和错误消息写入相应的日志文件,这样系统一旦出现问题就会"有据可查".此外,当主机遭受攻击时,日志文件还可以帮助寻找攻击者留下的痕迹.一.主要日志文件在Linux系统中,日志数据主要包括以下三种类型:[内核及系统日志][用户日志][程序日志]Linux系统本身和大部分服务器程序的日志文件默认情况下都放置在目录"/var/log"中.一部分程序公用一个日志文件,一部分程序使用单个

mysql的innodb中事务日志ib_logfile

mysql的innodb中事务日志ib_logfile事务日志或称redo日志,在mysql中默认以ib_logfile0,ib_logfile1名称存在,可以手工修改参数,调节开启几组日志来服务于当前mysql数据库,mysql采用顺序,循环写方式,每开启一个事务时,会把一些相关信息记录事务日志中(记录对数据文件数据修改的物理位置或叫做偏移量);作用:在系统崩溃重启时,作事务重做:在系统正常时,每次checkpoint时间点,会将之前写入事务应用到数据文件中.引入一个问题:在m/s环境中,in

MySQL中redo日志

重做日志用来实现事务的持久性,即ACID中的D,由两部分组成: 一是内存中的重做日志缓冲(redo log buffer)  易丢失 二是重做日志文件(redo log file) 持久的 InnoDB是事务的存储引擎,其通过Force Log at Commit 机制实现事务的持久性,即当事务提交commit时,必须先将事务的所有日志写入到重做日志文件进行持久化,待事务COMMIT操作完成才算完成,这里的日志指重做日志,在InnoDB存储引擎中,由两部分组成,即redo log 和undo L

Laravel中的日志与上传

PHP中的框架众多,我自己就接触了好几个.大学那会啥也不懂啥也不会,拿了一个ThinkPHP学了.也许有好多人吐槽TP,但是个人感觉不能说哪个框架好,哪个框架不好,再不好的框架你能把源码读上一遍,框架的设计思想理解了也能学到好多东西.况且有好多东西自己还不理解,所以认真学习一个框架这还是可以学不少东西的. 还是先说说Laravel吧,现在已经到5.2了.就我自己来说之前没有接触过laravel,但是学习过laravel之后感觉这个框架确实不错,并且老外用的不亦乐乎.他的开发社区还可以,文档比较齐

在/proc文件系统中增加一个目录hello,并在这个目录中增加一个文件world,文件的内容为hello world

一.题目 编写一个内核模块,在/proc文件系统中增加一个目录hello,并在这个目录中增加一个文件world,文件的内容为hello world.内核版本要求2.6.18 ? 二.实验环境 物理主机:win7 64bit, i5双核,8G内存 虚拟机:Vmware Workstation 10.0.2 虚拟主机: CentOs-5.11,内核2.6.18 ? 三.实验思路 在着手解决问题之前,我在网上查阅了一些资料,大多是关于模块的介绍.linux内核采用的是模块化编程,这样可以很容易的添加或

PHP框架中的日志系统

现在在一家公司做PHP后台开发程序猿(我们组没有前端,做活动时会做前端的东西),刚开始到公司的时候花2个周赶出了一个前端加后台的活动(记得当时做不出来周末加了两天班...),到现在过去4个多月了,可以用一下午秒掉一个不是很复杂的活动,当然了现在做的时候会考虑很多东西,比如说扩展性.可重用性,因为做的多了,会积累很多类似小插件的东西,所以会很快......但是我发现整天“站在需求里面做需求”很差劲,这样不会学到系统的.框架类的东西,因为都被琐碎的需求给困住了,没有时间去做一些框架重要部分的东西,而

文件系统中的journal device和write cache

众所周知,文件系统中的journal device主要有两个目的: 1.保证数据的一致性: 2.缩短写响应时间 要保证数据的一致性,当然避免不了和磁盘write cache的交互,这体现在两个层次: 1.文件系统中对journal device的写 充分利用journal device的写速度快的特点,写操作先到journal device设备,一次写到journal device的事务包括要写的data和下次取它才需要的最少的meta data.如何确保这些数据彻底落到journal devi

Hive数据导入——数据存储在Hadoop分布式文件系统中,往Hive表里面导入数据只是简单的将数据移动到表所在的目录中!

转自:http://blog.csdn.net/lifuxiangcaohui/article/details/40588929 Hive是基于Hadoop分布式文件系统的,它的数据存储在Hadoop分布式文件系统中.Hive本身是没有专门的数据存储格式,也没有为数据建立索引,只需要在创建表的时候告诉Hive数据中的列分隔符和行分隔符,Hive就可以解析数据.所以往Hive表里面导入数据只是简单的将数据移动到表所在的目录中! Hive的几种常见的数据导入方式这里介绍四种:(1).从本地文件系统中

游戏服务器中的日志处理方式之一

在游戏开发的过程中,我们需要记录一些日志,以便以后了解游戏运行的情况,以及根据日志发现并处理游戏中的突发情况. 一,游戏日志可以分为以下几种:1)系统日志2)用户操作日志3)异常日志,即错误日志 系统日志 系统日志一般描述的是服务器日常运行的状态.比如启动是否成功,每天统计一下内存的占用量,CPU的使用量等信息.用于查检服务器运行的健康状况.这对于技术分析来说是非常重要的.如果没有这些信息,一但服务器宕机,我们就两眼一抺黑,不知从何下手了.这部分日志一般产生的文件不大,内容不是太多,可以记录成文