soalris文件系统logging详解

看到一篇好文章,发给大空共享! Solaris中的logging功能的应用 在Solaris7及其以后版本的系统中有一种称为logging的功能。它不但易于安装和使用，并且对于数据安全非常有用。 UFS是存在于Sun工作站的几乎所有硬盘分区（swap等个别分区除外）上的一种标准的文件系统类型。而logging功能是UFS文件系统的一个挂接选项，它可以被设置在包括/在内的各个硬盘分区上。 Solaris的UFS logging通过使用系统中的空白数据块来工作。所有对文件系统数据（metadata，或称为元数据）的修改都被写在这些空白的区域。这些Metadata包括目录和inode信息，不包括文件中的数据本身。比如创建文件时，目录结构被修改并且系统为这个新文件分配一个新的inode。以上这些行为被写入做logging的空间中。一旦数据的修改行为被写入做logging的区域，系统就可以接着对文件系统做其它的操作了。在后台，存在于logging中的信息将被同步到文件系统中，并自动更新相应的目录和I节点，最终完成文件系统的操作。数据也陆续被写入硬盘。因此这种做logging并在后台写入数据，比通过随机的I/O访问直接对分布在硬盘上的各种管理信息进行修改的方式速度要快得多。用来做logging的空间的大小取决于文件系统的大小。每1GB磁盘分区空间的logging空间为1MB，最多不超过64MB。这部分logging空间被循环使用：当log空间即将装满时，暂停新的metadata数据写入，直至log空间被清空。当log中记录的关于文件系统的修改都被应用于文件系统后，那部分空间又重新可以作为log空间来存放新的metadata数据了。 通常对于UFS来说，如果操作系统在任何文件系统操作中崩溃，整个文件系统都需要用fsck命令做一致性检查。这个命令的执行可能需要几分钟的时间，因为它需要检测所有的metadata和文件的数据以确认文件系统的完整性：包括当前已经用的空间、未用的、inode的数量等，修复其中不一致的地方。出现比较大的问题时还需要人工干预。在做检查的过程中有可能会丢失文件，甚至目录。这决定于crash发生时，该操作进行到了哪种程度。如果采用logging功能，情况就完全不同。因为metadata的修改首先被写在log空间而不是文件系统中。如果系统崩溃，对文件系统一致性的检测可以仅仅限于log中记录的那部分，这样会更简单、更有效。系统检查logging的数据，以决定在上一次的文件系统中，哪种修改已经做过了，哪种修改即将做，哪种修改正在做， 做过的和即将做但还没有做的操作被系统从log中删掉， 而那些做了一部分的会被接着做完或完全取消掉。如果在log中记录了足够的数据来完成这一操作，该操作会被继续完成。否则，这种改变会被取消。熟悉数据库操作的用户会发现这和数据库软件中的事务处理过程非常相似。最终的结果是：文件系统能够最大限度地保持一致，不需要进行彻底的文件系统检测，整个文件系统检测过程只需要花几秒钟时间。从Solaris 7开始, mount命令和/etc/vfstab文件中也有了一个新的logging选项。 为了验证logging选项对系统性能的贡献，我们做一个脚本文件，它要创建1000个目录。这种操作将对系统中的metadata的处理带来非常大的压力。实验在一台运行Solaris7的Ultra 5机器上进行： # more logging-test #!/bin/ksh # Test ufs logging performance # Get to the right place and make a test directory cd /big mkdir test # Create 1000 directories integer i=0 while ((i