Windows LiveWindows Live™
 
 
在's profile不在PhotosBlogLists Tools Help

Categories
日杂Subscribe to RSS feed
软件相关Subscribe to RSS feed
硬件相关Subscribe to RSS feed
*NIXSubscribe to RSS feed
架站Subscribe to RSS feed
健康与保健Subscribe to RSS feed

Blog list

不在

Blog
04/11/2006

NetBSD Bookmarks

Download Systems


News


Main Websites


Packages


Blogs


Forums


Other Websites


User's Docs


PDF Docs


NetBSD LiveCD, Floppy, Flash and Others


NetBSD Books


NetBSD Culture


NetBSD: Articles, Advocacy, Reviews


NetBSD - Technical Articles in Polish (warpman's selection)


NetBSD - Technical Articles in English (warpman's selection)


Firms Offering NetBSD Systems

  • Polish
  • Foreign
  • iXsystems - the firm acquired PC-BSD
    iXsystems is a leading provider of high-performance computing clusters, blade servers, rackmount servers, and storage solutions to the global marketplace. iXsystems supplies FreeBSD, NetBSD, OpenBSD and Linux servers to a wide cross-section of industries."

Varia


12:27:19 PM | Add a comment | Read comments (5) | Permalink | Blog it | *NIX
05/10/2006

少林医药（局方）

少林医药（局方）
6:16:49 PM | Add a comment | Read comments (2) | Permalink | Blog it | 健康与保健
29/05/2006

OnLamp.com的Clean up ports

 
FreeBSD ports即便得到所有赞美，也存有局限性。其中之一实际上来自它的强项-upgrade系统。两者以一种郁闷的方式互相影响。
port安装过程记录一个port所include的所有文件和所有依赖。比如，许多ports需要PNG图形库。port记录它使用的PNG版本，如1.0.11。当你安装了一部分软件，这一般和可以在ports树中找到是相同的版本。FreeBSD upgrade进程可以升级被port tree支持的软件版本。比如，PNG最近升级到1.0.12版本，库版本号没有增加，但是新库有一些小bug修复。我想升级。但是如果我那样做了，编码了确切PNG版本号的30多个ports将得到错误记录。
?
我的笔记本有187个包（packages）。我一个星期升级一次。这很快就变得零乱，不久之后就难以忍受。幸好，Akinori MUSHA has stepped up to the plate（怎么翻译）并开发了一套可以整理这种零乱状态的工具：portupgrade(1)和他的朋友们（小熊温尼和他的朋友们）。
portupgrade中包含的工具实现了port系统的新特性。首先是pkgdb
和portdb，用来对/var/db/pkg索引和ports树创建数据库。这样能加快搜索并操作之。这些工具也可以重写/var/db/pkg里不同的文件来维护一致性。最后是各种pkg_*命令的wrappers，当添加或删除软件时可以用来重写数据库和纯文本记录。所有这些可以通过安装/usr/ports/sysutilis/portupgrade来得到。
在开始使用portupgrade之前，备份 /var/db/pkg！我从没在这个程序上遇到过麻烦，但是任何可以直接改写系统记录的工具具有无限可能使你的生活一团糟。如果你完全破坏了package records，你需要还原它：
#tar -czvf dbpkg.tgz /var/db/pkg
运行pkgdb -F 来初始化安装，并进行基本的清理工作。如果你有许多ports，并已升级过几次port树。第一次时应留出一定时间。一旦有了一致性的数据库，维护将是又快又easy的；只是第一次会比较耗时。
 
    #pkgdb -F
    Checking the origin of Hermes-1.3.2
    Checking the origin of Mesa-3.4.1
    Checking the origin of Mesa-3.4.2_1
    Checking the origin of ORBit-0.5.10_5
    Checking the origin of XFree86-aoutlibs-3.3.6.9
    …

当遇到依赖改变的包时，pkgdb会询问是否要修改。

    Stale dependency: esound-0.2.22 -> libaudiofile-0.2.2:
    libaudiofile-0.2.1_1 ? ([y]es/[n]o/[a]ll) [yes]

esound已经记录libaudiofile版本0.2.2作为依赖，但是安装的是版本0.2.1_1。我也许过去做过pkg_add -f,以强制安装尽管有微小版本差异。问我是否想要更新我在/var/db/pkg/esound-0.2.22/+CONTENTS的入口来指向实际安装的libaudiofile的版本。如果默认，他将修改入口记录，如果输入“a”，不仅修改libaudiofile对于esound的入口，而且还修改所有用到libaudiofile的其他包。这对于具有很多依赖的包比如PNG，显得格外方便。
在之前的例子里，pkgdb可以对依赖性进行智能推测。另一方面，它不能推测所有事情。比如，我从xfree86.org的CVS主机上编译XFree86.imake是free86的一部分，所以在/var/db/pkg中没有相应记录。好；port编译过程check已安装的，并且没有在/var/db/pkg记录的包。当一个port安装后，记录写进/var/db/pkg中，然而前提是如go建立程序port在那里。（这是一个可论证的port的缺陷，但是还没有简易的修复办法）
这意味着当一个ports列出imake作为依赖时，pkgdb将卡壳

    Stale dependency: Xaw3d-1.5 -> imake-4.1.0:
    New dependency? (? to help): ?

这里我有一个选项。我可以指派一个新的依赖，或我可以告知package已经不再有什么依赖了。当Xaw3d需要imake，我知道在这个特别的系统里，它不会发现imake已经安装了。我想要删除依赖性。如果敲”?”来查看帮助会发现：

    [Enter] to skip, [Ctrl]+[D] to delete, [.][Enter] to abort, [Tab] to complete
    New dependency? (? to help):?

     

    Control-D it is.
    Delete this? ([y]es/[n]o/[a]ll) [yes]
    Deleted.

如果我选择“YES”，将清除该依赖。如果我选择“all”将清除所有该依赖无论何时出现。许多ports使用imake；我都想清除。稍后你将看到：

    Stale dependency: xneko-4.4 -> XFree86-libraries-4.1.0:
    Delete this? ([y]es/[n]o/[a]ll) [yes] Deleted.

还有几次，在别处也出现了pkgdb不能推测依赖的情况

    Stale dependency: plugger-3.3_1 -> timidity++-esound-2.10.4:
    New dependency? (? to help): ?
    [Enter] to skip, [Ctrl]+[D] to delete, [.][Enter] to abort, [Tab] to complete
    New dependency? (? to help): timidity++-2.10.4

用tab可以完成。我知道timidity++-esound用到某版本的timedity，但是我不想挖地三尺以求整个完整的版本号。我可以输入前两个字母然后按Tab键，就得到了剩下的包的名字。
最后，在整个过程的最后，pkgdb将提请你关于副本：

    Duplicated origin: graphics/Mesa3 - Mesa-3.4.1 Mesa-3.4.2_1
    Remove any of them? [no]

这里我有一个问题。从一个包安装软件而需要另外一个包的情况是很疏松平常的。也许你已安装的包有一点版本出入。如果你正通过package来安装，它会自动安装依赖，即使稍有出入的版本已经安装了。这有时会在我的系统中出现。我的本本有两个不同版本的Mesa，但是一个已经覆盖了另一个。这明显的不能算最糟糕的，因为我的系统还在工作。（最后我完全删除了mesa并安装了适合的版本）。尽管如此我依然需要清理packge数据库。我手动卸载了老版本。
现在你有了package的数据库信息，/var/db/pkg/pkgdb.db。也有了一个port数据库，/usr/ports/index.db和/usr/ports/index.dbo.各种portuprade工具使用这些数据库来完成魔术般的操作.无论何时升级ports树,都要升级ports数据库和/usr/ports/INDEX.可以通过portsdb -Uu来轻易完成.
现在我们已经装好了工具,来看看我们可以干些什么.想看哪些是过时的,使用portversion(1).这个命令和pkg_info的工作方式相同,但是速度更快.

    # portversion
    Hermes =
    Mesa =
    ORBit <
    XFree86-aoutlibs <
    Xaw3d =
    aalib =

<代表安装的版本比port树中的旧.可以通过运行portversion | grep '<'来查看哪些port过时了.我经常使用它来查看自己的系统.比如,我的Apache过时了.但是在我的本本上我已经不使用apache了,所以我可以删除它.标准的pkg_delete命令仍然适用,但是我用了,我的package数据库将同我的系统失去同步.使用pkg_deinstall来代替.

    # pkg_deinstall apache
    —< Deinstalling 'apache-1.3.20'
    [Updating the pkgdb in /var/db/pkg ... - 182 packages found (-1 +0) (...) done]
    #

好处是我再也不用给出完整版本号!(对于FreeBSD的pkg_*,这困扰我良久,但是无能为力).portupgrade工具包含全局函数，可以进行模式匹配。
我打算升级特定的ports，而且，我要升级的同时保持数据库同步，跟新入口记录到/var/db/pkg。比如portversion高速我gd过时了。升级工作很简单:

    # portupgrade gd
    ===> Cleaning for gettext-0.10.35
    ===> Cleaning for gmake-3.79.1
    ===> Cleaning for libtool-1.3.4_2
    ===> Cleaning for jpeg-6b
    ===> Cleaning for png-1.2.0
    ===> Cleaning for freetype2-2.0.5
    ===> Cleaning for gd-1.8.4_4
    If you want to compile in X support use
    ‘make -DWITH_X11′ instead
    ===> Extracting for gd-1.8.4_4
    ….

将看到熟悉的make输出界面。如果继续观察，会发现转而去卸载已安装的包，更新数据库，然后继续。

    … —> Deinstalling ‘gd-1.8.4_3′
    pkg_delete: package ‘gd-1.8.4_3′ is required by these other packages and may not be deinstalled (but I’ll delete it anyway):
    scr2png-1.1
    [Updating the pkgdb in /var/db/pkg … - 180 packages found (-1 +0) (…) done]
    ===> Installing for gd-1.8.4_4
    …

一旦安装完成，会再一次更新package数据库。所有的都是同步的。
现在让我们看一个难点的。我的docproj port过时了。docporj是不包含任何东西的，但是同每个编辑FreeBSD Document Project的工具有依赖。如果经常建立文档树，这个工具需要更新。还有，你不想递归重编译所有，只想做小的更新；docproj有着庞大的依赖。
如果打算节约时间，可以用portupgrade -P来告诉portupgrade使用package安装。我不缺时间所以我用port。我们需要告知portupgrade来递归更新，将更新被docproj用到的包。可以使用-R标志，试试：

    # portupgrade -R docproj
    This port will try to ensure that the tools used by the FreeBSD
    Documentation Project are installed on your system so you can convert documentation from SGML to other formats.

组件其中之一是JadeTex,它依赖于TeTex。TeTex的源代码超过30M，可能需要很长的下载时间。
如果不打算从文档产生PostScript和PDF格式，就不需要JadeTex，你应当将JADETEX变量设为“NO”。如果希望输出PostScript和PDF，则设为“YES”。
比如：

    make JADETEX=no
    make JADETEX=yes?

     

    *** Error code 1

    Stop.
    ** Command failed: make clean build
    ** Fix the problem and try again.
    ** The following packages were not installed or upgraded (-:skipped /
    !:failed)
    ! textproc/docproj (docproj-1.4) (unknown build error)
    #

我考。这个port需要定制。你可以修改/usr/ports/textproc/docproj/Makefile添加 JADETEX=no。现在它将完全透明得运行。
完成后，可以用portversion来查看发生了什么。你可能会发现其他的port依赖也已改写。比如，如果port A依赖于Port B，但是port C也依赖于Port B，运行portupgrade A将不会修改Port C的依赖。随时准备用pkgdb -F来发现和修复类似问题。
如果你打算让系统自己来处理这些事情，使用portupgrade -rR；这将升级此依赖的和依赖于此的ports。如果想要自己的系统有最新的软件，这里提供了一种方式。portupgrade包含了使FB软件管理简单化的多种工具，但这足以使你起步。
你可能会发现不得不从一个相同的distfile重编译一个port很多次。如果port改变了，portversion将发现并标记为过时。你想保留安装了的port的distfile，然后删除旧的distfile。portsclean -D将完成这些工作。相同的，你可能打算删除在package数据库中不被引用的共享库。我不使用上面的参数。别忘了我安装XFree86以抓包的方式而不是port。这个命令（portclean -D）将会删除我的X安装，我考！但是portsclean -L可以办到，并且可以帮助处理一些问题，比如我的不完全安装的Mesa的垃圾文件。
最后，我必须说这个工具似乎相当鲁棒。文章的结尾，我运行这个程序来证明我的说法。我注意到了一个旧的包，简单的升级了它：

    # portupgrade -R portupgrade

是的，没错它可以，我说过的它真是好样的。

original:Michael W. Lucas
tans. wonglaye

12:24:32 AM | Add a comment | Read comments (3) | Permalink | Blog it | *NIX
26/05/2006

Linux日志文件系统及性能分析(组图)

　　日志文件系统可以在系统发生断电或者其它系统故障时保证整体数据的完整性，Linux是目前支持日志文件系统最多的操作系统之一，本文重点研究了Linux常用的日志文件系统：EXT3、ReiserFS、XFS和JFS日志技术，并采用标准的测试工具PostMark和 Bonnie++对它们进行了测试，给出了详细的性能分析，对Linux服务器应用具有重要的参考价值。
　　
　　一、概述
　　
　　所谓日志文件系统是在传统文件系统的基础上，加入文件系统更改的日志记录，它的设计思想是：跟踪记录文件系统的变化，并将变化内容记录入日志。日志文件系统在磁盘分区中保存有日志记录，写操作首先是对记录文件进行操作，若整个写操作由于某种原因(如系统掉电)而中断，系统重启时，会根据日志记录来恢复中断前的写操作。在日志文件系统中，所有的文件系统的变化都被记录到日志，每隔一定时间，文件系统会将更新后的元数据及文件内容写入磁盘。在对元数据做任何改变以前，文件系统驱动程序会向日志中写入一个条目，这个条目描述了它将要做些什么，然后它修改元数据。目前Linux的日志文件系统主要有：在Ext2基础上开发的Ext3，根据面向对象思想设计的ReiserFS，由SGI IRIX系统移植过来的XFS，由IBM AIX系统移植过来的JFS，其中EXT3完全兼容EXT2，其磁盘结构和EXT2完全一样，只是加入日志技术；而后三种文件系统广泛使用了B树以提高文件系统的效率。
　　
　　二、Ext3
　　
　　Ext3 文件系统是直接从Ext2文件系统发展而来，目前Ext3文件系统已经非常稳定可靠，它完全兼容Ext2文件系统，用户可以平滑地过渡到一个日志功能健全的文件系统。Ext3日志文件系统的思想就是对文件系统进行的任何高级修改都分两步进行。首先，把待写块的一个副本存放在日志中；其次，当发往日志的 I/O 数据传送完成时（即数据提交到日志），块就写入文件系统。当发往文件系统的I/O 数据传送终止时（即数据提交给文件系统），日志中的块副本就被丢弃。
　　
　　2.1 Ext3日志模式
　　
　　Ext3既可以只对元数据做日志，也可以同时对文件数据块做日志。具体来说，Ext3提供以下三种日志模式：
　　
　　日志（Journal ）
　　
　　文件系统所有数据和元数据的改变都记入日志。这种模式减少了丢失每个文件所作修改的机会，但是它需要很多额外的磁盘访问。例如，当一个新文件被创建时，它的所有数据块都必须复制一份作为日志记录。这是最安全和最慢的Ext3日志模式。
　　
　　预定（Ordered ）
　　
　　只有对文件系统元数据的改变才记入日志。然而，Ext3文件系统把元数据和相关的数据块进行分组，以便把元数据写入磁盘之前写入数据块。这样，就可以减少文件内数据损坏的机会；例如，确保增大文件的任何写访问都完全受日志的保护。这是缺省的Ext3 日志模式。
　　
　　写回（Writeback ）
　　
　　只有对文件系统元数据的改变才记入日志；这是在其他日志文件系统发现的方法，也是最快的模式。
　　
　　2.2 日志块设备（JBD）
　　
　　Ext3 文件系统本身不处理日志，而是利用日志块设备（Journaling Block Device）或叫JBD 的通用内核层。Ext3文件系统调用JDB例程以确保在系统万一出现故障时它的后续操作不会损坏磁盘数据结构。Ext3 与JDB 之间的交互本质上基于三个基本单元：日志记录，原子操作和事务。
　　
　　日志记录本质上是文件系统将要发出的低级操作的描述。在某些日志文件系统中，日志记录只包括操作所修改的字节范围及字节在文件系统中的起始位置。然而，JDB 层使用的日志记录由低级操作所修改的整个缓冲区组成。这种方式可能浪费很多日志空间（例如，当低级操作仅仅改变位图的一个位时），但是，它还是相当快的，因为JBD 层直接对缓冲区和缓冲区首部进行操作。
　　
　　修改文件系统的任一系统调用都通常划分为操纵磁盘数据结构的一系列低级操作。如果这些低级操作还没有全部完成系统就意外宕机，就会损坏磁盘数据。为了防止数据损坏，Ext3文件系统必须确保每个系统调用以原子的方式进行处理。原子操作是对磁盘数据结构的一组低级操作，这组低级操作对应一个单独的高级操作。
　　
　　出于效率的原因，JBD 层对日志的处理采用分组的方法，即把属于几个原子操作处理的日志记录分组放在一个单独的事务中。此外，与一个处理相关的所有日志记录都必须包含在同一个事务中。一个事务的所有日志记录都存放在日志的连续块中。JBD层把每个事务作为整体来处理。例如，只有当包含在一个事务的日志记录中的所有数据提交给文件系统时才回收该事务所使用的块。
　　
　　三、ReiserFS
　　
　　ReiserFS 是一个非常优秀的文件系统，其开发者非常有魄力，整个文件系统完全是从头设计的。目前，ReiserFS可轻松管理上百G的文件系统，这在企业级应用中非常重要。ReiserFS 是根据面向对象的思想设计的，由语义层（semantic layer)和存储层（storage layer)组成。语义层主要是对对象命名空间的管理及对象接口的定义，以确定对象的功能。存储层主要是对磁盘空间的管理。语义层与存储层是通过键（key）联系的。语义层通过对对象名进行解析生成键，存储层通过键找到对象在磁盘上存储空间，键值是全局唯一的。
　　
　　3.1 语义层主要接口
　　
　　1) 文件接口 每个文件拥有一个接口ID，此ID标识一个方法集，此方法集包含访问ReiserFS 文件的所有接口。
　　
　　2) 属性接口 ReiserFS实现了一种新接口，把文件的每一种属性当做一个文件，属性的值就是此文件的内容，以实现对文件属性的目录式访问。
　　
　　3) hash接口 目录是文件名到文件的映射表，ReiserFS是通过B＋树来实现这张映射表。由于文件名是变长的，而且有时文件名会很长，所以文件名不适合作为键值，故引入了Hash函数来产生键值。
　　
　　4) 安全接口 安全接口处理所有的安全性检查，通常是由文件接口触发的。下面以读文件为例：文件接口的read 方法在读入文件数据之前会调用安全接口的read chech 方法来来进行安全性检查,而后者又会调用属性文件的read方法把文件属性读入以便检查。
　　
　　5) 项（Item）接口 项接口主要是一些对项进行平衡处理的方法，包括：项的拆分，项的评估，项的覆写，项的追加，项的删除，插入及查找。
　　
　　6) 键分配（key Assignment）接口 当把一个键分配给一个项时，键分配接口就会被触发。每一种项都有一个与其对应的键分配方法。
　　
　　3.2 存储层
　　
　　ReiserFS是以B+树来存储数据的,其结构如图：
　　
　　图1：ReiserFS B+ 树
　　 　
　　在B+树中的各个结点中有一个称为项（Item）的数据结构。项是一个数据容器，一个项只属于一个结点，是结点管理空间的基本单位。如图所示，一个项包括以下内容：
　　
　　1) Item_body：项的数据域
　　
　　2) Item_key： 项的键值
　　
　　3) Item_offset：数据域的起点在结点中的偏移量
　　
　　4) Item_length： 数据域的长度
　　
　　5) Item_Plugin_id：项接口ID。
　　
　　图2： ReiserFS 项结构
　　 　
　　ReiserFS设计了多种不同的项以存储不同的数据，主要有以下几种：
　　
　　1) static_stat_data： 静态统计数据，包括文件的所有者，访问权限，创建时间，最近修改时间，链接数等
　　
　　2) cmpnd_dir_item： 包含各个目录项
　　
　　3) extend_pointers： 指向一个盘区（extend）
　　
　　4) node_pointers： 指向一个结点
　　
　　5) bodies： 包含的是文件的小部分数据
　　
　　3.3 ReiserFS日志
　　
　　与ext3 一样，ReiserFS也有三种日志模式，即journal,ordered,writeback。同时，ReiserFS引入了两种日志优化方法： copy-on-capture和steal-on-capture。copy-on-capture:当一个事务要修改的块在另一个未提交的事务中时，就把这个块复制一份，这样这两个事务就可以并发进行了。steal-on-capture：当一个块被多个事务修改时，只有最晚提交的那个事务才把这个块实际写入文件系统，其他事务都不写这个块。
　　
　　四、XFS
　　
　　XFS 是一种高性能的64 位文件系统，由SGI 公司为了替代原有的EFS 文件系统而开发的。XFS 通过保持cache 的一致性、定位数据和分布处理磁盘请求来提供对文件系统数据的低延迟、高带宽的访问。目前SGI已经将XFS文件系统从IRIX移植到Linux。
　　
　　4.1 分配组（allocation groups）
　　
　　当创建 XFS 文件系统时，底层块设备被分割成八个或更多个大小相等的线性区域（region），用户可以将它们想象成"块"（chunk）或者"线性范围（range）"，在 XFS 中，每个区域称为一个"分配组"。分配组是唯一的，因为每个分配组管理自己的索引节点（inode）和空闲空间，实际上是将这些分配组转化为一种文件子系统，这些子系统透明地存在于 XFS 文件系统内。有了分配组，XFS 代码将允许多个线程和进程持续以并行方式运行，即使它们中的许多线程和进程正在同一文件系统上执行大规模 IO 操作。因此，将 XFS 与某些高端硬件相结合，将获得高性能而不会使文件系统成为瓶颈。分配组在内部使用高效的 B+树来跟踪主要数据，具有优越性能和极大的可扩展性。
　　
　　4.2 日志记录
　　
　　XFS 也是一种日志记录文件系统，它允许意外重新引导后的快速恢复。象 ReiserFS 一样，XFS 使用逻辑日志；它不象 ext3 那样将文字文件系统块记录到日志，而是使用一种高效的磁盘格式来记录元数据的变动。就 XFS 而言，逻辑日志记录是很适合的；在高端硬件上，日志经常是整个文件系统中争用最多的资源。通过使用节省空间的逻辑日志记录，可以将对日志的争用降至最小。另外，XFS 允许将日志存储在另一个块设备上，例如，另一个磁盘上的一个分区。这个特性很有用，它进一步改进了 XFS 文件系统的性能。
　　
　　4.3 延迟分配
　　
　　延迟分配是 XFS 独有的特性，它是查找空闲空间区域并用于存储新数据的过程。通过延迟分配，XFS 赢得了许多机会来优化写性能。到了要将数据写到磁盘的时候，XFS 能够以这种优化文件系统性能的方式，智能地分配空闲空间。尤其是，如果要将一批新数据添加到单一文件，XFS 可以在磁盘上分配一个单一、相邻区域来储存这些数据。如果 XFS 没有延迟它的分配决定，那么，它也许已经不知不觉地将数据写到了多个非相邻块中，从而显著地降低了写性能。但是，因为 XFS 延迟了它的分配决定，所以，它能够一下子写完数据，从而提高了写性能，并减少了整个文件系统的碎片。在性能上，延迟分配还有另一个优点。在要创建许多"短命的"临时文件的情况下，XFS 可能根本不需要将这些文件全部写到磁盘。因为从未给这些文件分配任何块，所以，也就不必释放任何块，甚至根本没有触及底层文件系统元数据。
　　
　　五、JFS
　　
　　JFS 由IBM 公司开发，最初出现在AIX 操作系统之上，它提供了基于日志的字节级、面向事务的高性能文件系统。它具有可伸缩性和健壮性，与非日志文件系统相比，它的优点是其快速重启能力：JFS 能够在几秒或几分钟内就把文件系统恢复到一致状态。JFS 是完全 64 位的文件系统。所有 JFS 文件系统结构化字段都是 64 位大小。这允许 JFS 同时支持大文件和大分区。
　　
　　为了支持 DCE DFS（分布式计算环境分布式文件系统），JFS 将磁盘空间分配池（称为聚集）的概念, 与可安装的文件系统子树（称为文件集）的概念分开。每个分区只有一个聚集；每个聚集可能有多个文件集。在第一个发行版中，JFS 仅支持每个聚集一个文件集；但是，所有元数据都已设计成适用于所有情况。
　　
　　如图3所示，聚集开始部分是32K的保留区，紧随其后的是聚集主超级块。超级块包含聚集的信息，例如：聚集的大小、分配组的大小、聚集块的尺寸等等。超级块位于固定位置，这使得 JFS 不依赖任何其它信息，就能够找到它们。在聚集中还有一个重要的结构是聚集索引结点表（Aggregate Inode Table）以及用于其映射的聚集索引结点分配映射表（Aggregate Inode Allocation Map）。AIT表中的inode 0 保留，inode 1 描述聚集本身，inode 2 描述聚集块映射表（block map）， inode 3 描述安装时的内嵌日志，inode 4 描述在聚集格式化期间发现的坏块，保留inode 5 到 15 以备将来扩展。 从inode 16 开始，每个inode代表一个文件集。文件集中也有索引结点表以及用于其映射的索引结点分配映射表，文件集中的inode 描述文件集中的每一个文件。
　　
　　图3 JFS磁盘结构
　　 　
　　JFS 使用基于盘区的寻址结构，连同主动的块分配策略，产生紧凑、高效、可伸缩的结构，以将文件中的逻辑偏移量映射成磁盘上的物理地址。盘区是象一个单元那样分配给文件的相连块序列，可用一个由 <逻辑偏移量，长度，物理地址> 组成的三元组来描述。寻址结构是一棵 B+ 树，该树由盘区描述符（上面提到的三元组）填充，根在 inode 中，键为文件中的逻辑偏移量。
　　
　　JFS 按需为磁盘 inode 动态地分配空间，同时释放不再需要的空间。这一支持避开了在文件系统创建期间，为磁盘 inode 保留固定数量空间的传统方法，因此用户不再需要估计文件系统包含的文件和目录最大数目。另外，这一支持使磁盘 inode 与固定磁盘位置分离。
　　
　　JFS 提供两种不同的目录组织。第一种组织用于小目录，并且在目录的 inode 内存储目录内容。这就不再需要不同的目录块 I/O，同时也不再需要分配不同的存储器。最多可有 8 个项可直接存储在 inode 中，这些项不包括自己(.)和父(..)目录项，这两个项存储在 inode 中不同的区域内。第二种组织用于较大的目录，用按名字键控的 B+ 树表示每个目录。与传统无序的目录组织比较，它提供更快的目录查找、插入和删除能力。
　　
　　六、性能测试
　　
　　6.1 测试环境
　　 　
　　6.2测试工具
　　
　　所用的测试工具是Postmark和Bonnie++。Postmark主要用于测试文件系统在邮件系统或电子商务系统中性能，这类应用的特点是：需要频繁、大量地存取小文件。而Bonnie++主要测试大文件的IO性能。
　　
　　6.3 测试结果分析
　　
　　下面将详细分析用上述两种测试工具在各种测试参数配置下的结果。
　　
　　图4 PostMark 小文件
　　 　
　　图 4是PostMark测试小文件的结果，其参数是文件大小50B增至1K, 同一目录下的文件数从5k至20k，事务总数为25k。从图中我们可以看出：
　　
　　1. 不论是Ext3 还是ReiserFS,在三种日志模式中，写回（writeback）最快，预定（ordered）次之，日志（journal）最慢。
　　
　　2. 在各种文件系统中，ReiserFS 的写回和预定模式是最快的，且随着文件数的增加事务处理速度下降的也很慢。
　　
　　3. Ext3在文件数较少时，事务处理速度也比较快，但当文件数超过10k后，速度就比较慢了。
　　
　　4. XFS和JFS的速度较慢，但随着文件数的增加，速度下降的比较缓慢。
　　
　　图5 PostMark 大文件
　　 　
　　图5是PostMark测试大文件的结果，其参数是文件大小1k至16K,同一目录下的文件数从5k增至20k，事务总数为25k时的测试结果。从图中我们可以看出：
　　
　　1. 在处理大文件时，当文件数达到15k时，各种文件系统处理能力都较差。
　　
　　2. 当文件数在小于10k时，ReiserFS的写回、预定模式和EXT3的写回模式性能是比较好的。但这两种文件系统的全日志模式都比较差。
　　
　　3. XFS文件系统的性能居中，JFS文件系统的性能最差。
　　
　　图6：Bonnie++顺序写的速率
　　 　
　　图7：Bonnie++顺序写时CPU利用率
　　 　
　　图6是Bonnie++对文件大小分别为1G，2G，4G顺序写的性能比较，图7是其CPU的利用率比较。从上述两图中我们可以看出：
　　
　　1. 除了Ext3和ReiserFS的Journal模式的性能较差外，其他几种模式和XFS、JFS写磁盘的速率相当。
　　
　　2. 从CPU利用率来看，各种文件系统的CPU利用率都比较低，而且随着数据量的增大CPU的利用率降低。
　　
　　3. Journal模式的CPU利用率比其他两种模式要低。
　　
　　图8：Bonnie++ 顺序创建文件
　　 　
　　图9：Bonnie++ 随机创建文件
　　 　
　　图10：Bonnie++ 随机删除文件
　　 　
　　图11：Bonnie++ 随机删除文件时的CPU利用率
　　
　　图8至图11是Bonnie++对创建和删除文件的性能比较，文件数由50k增至400k。从中可以看出：
　　
　　1. 不管是创建文件，还是删除文件，Ext3和ReiserFS的三种日志模式之间的性能差别可以忽略不计。这主要是由于创建、删除文件都是对元数据的操作，而对元数据的操作三种模式之间本身就没有什么区别。
　　
　　2. 不管是创建文件，还是删除文件，Ext3的性能都比较差；ReiserFS的性能是最好的，特别是文件数少于100k时。这主要是由于Ext3是基于Ext2的，其目录项是线性组织的，而其他文件系统都是树形结构。
　　
　　3. 从CPU的利用率来看，除Ext3的利用率交给外，其他几种文件系统的利用率都很低。
　　
　　综上所述，我们可以得出以下结论：
　　
　　1. 在小型系统，如：邮件系统或小规模的电子商务系统应用时，ReiserFS和Ext3 的性能是比较好的。但由于Ext3的目录项是线型的，而ReiserFS的目录项是树型的，故当目录下文件较多时，ReiserFS的性能更优。
　　
　　2. 在对于上G的这种大文件做I/O时，各种文件系统间的性能差距很小，性能瓶颈往往在磁盘上。
　　
　　3. 虽然XFS和JFS在设计结构上都比较好，但它们主要是针对大中型系统的，在小型系统中由于硬件的原因性能发挥不明显。
　　
　　4. 全日志模式和预定、写回这两种模式相比，性能差距是比较大的；而预定和写回之间的性能差距不大。所以性能和安全兼顾时，文件系统的缺省安全模式，即预定模式是比较好的选择。

7:39:06 PM | Add a comment | Read comments (1) | Permalink | Blog it | *NIX
02/04/2006

博客是两类人在玩

博客是两类人在玩，一类是比较自恋的人在写，一类是想了解别人的隐私，喜欢偷窥的人在看
 
金山公司副总裁——高宁宁语
 
 
进来看我这贴的都是偷窥狂
9:47:52 PM | Add a comment | Read comments (1) | Permalink | Blog it | 日杂