📄 00000004.htm

📁 一份很好的linux入门资料
💻 HTM
📖 第 1 页 / 共 3 页
字号:
12 3 下一页
<HTML><HEAD>  <TITLE>BBS水木清华站∶精华区</TITLE></HEAD><BODY><CENTER><H1>BBS水木清华站∶精华区</H1></CENTER>发信人:&nbsp;BlueOcean&nbsp;(Blue),&nbsp;信区:&nbsp;Unix&nbsp;<BR>标&nbsp;&nbsp;题:&nbsp;好书共赏－《Unix&nbsp;Internels》（四）&nbsp;<BR>发信站:&nbsp;BBS&nbsp;水木清华站&nbsp;(Tue&nbsp;Apr&nbsp;28&nbsp;01:07:10&nbsp;1998)&nbsp;<BR>&nbsp;<BR>&nbsp;<BR>Chapter&nbsp;11&nbsp;Advanced&nbsp;File&nbsp;Systems&nbsp;<BR>&nbsp;<BR>首先提到interleave的问题.不懂interleave的人可以看这里.&nbsp;这里提到一个关键&nbsp;<BR>性的bench&nbsp;mark.&nbsp;Unix&nbsp;filesytem的效率在於写入资料的速度.&nbsp;因为Unix系统的&nbsp;<BR>cache作的已经很好了,&nbsp;所以read()大部份都发生在cache上,&nbsp;但是write()则必须&nbsp;<BR>把资料写到硬碟去,变成了bottleneck.&nbsp;如何改善write()的速度就可以提升&nbsp;<BR>整体效率.&nbsp;<BR>&nbsp;<BR>皆下来讨论kernel要如何把资料写到disk上,在crash时有最小的&nbsp;损失,&nbsp;<BR>fsck才能够做到最大的复原.&nbsp;<BR>&nbsp;<BR>File&nbsp;System&nbsp;Clustering&nbsp;(Sun-FFS)&nbsp;<BR>&nbsp;<BR>一般的档案存取都是sequential的,虽然会透过好几个read/write&nbsp;system&nbsp;call&nbsp;<BR>达成.&nbsp;如果kernel也可以像C&nbsp;stdio一样收集这些data&nbsp;block,然後再一起写到&nbsp;<BR>disk去可以增加效率,这就是file&nbsp;system&nbsp;clustering.&nbsp;SunOS首先提出这种办法,&nbsp;<BR>後来SVR4和4.4BSD也都采用了.&nbsp;file&nbsp;system&nbsp;clustering提升了不少FFS的效率,&nbsp;<BR>使得FFS仍然足以与新提出的档案系统匹敌.&nbsp;<BR>&nbsp;<BR>&nbsp;<BR>The&nbsp;Journaling&nbsp;Approach&nbsp;<BR>&nbsp;<BR>这里logging&nbsp;=&nbsp;journaling,&nbsp;意思是记录.&nbsp;journaling&nbsp;file&nbsp;system&nbsp;or&nbsp;&nbsp;<BR>logging&nbsp;file&nbsp;system&nbsp;(jfs&nbsp;or&nbsp;lfs)基本上就是把对file&nbsp;system的修改&nbsp;<BR>(包括对档案属性,档案内容,档案大小的修改)都以append&nbsp;only的方式附&nbsp;<BR>加(记录)到单一的档案(磁碟空间)去.最主要的目的是crash之後,只有最&nbsp;<BR>後append的部份有可能出问题,&nbsp;fsck的速度极快(只要放弃最後那段log&nbsp;<BR>就可以了).&nbsp;不过这样说好像太简单了,实际上lfs还要复杂些,有些race&nbsp;<BR>&nbsp;condition要处理.&nbsp;<BR>&nbsp;<BR>一个档案由两个资料组成,&nbsp;一个是data,&nbsp;另一个叫meta-data,指的是档案&nbsp;<BR>的permission,access&nbsp;time,&nbsp;modify&nbsp;time,...等等.&nbsp;<BR>&nbsp;<BR>我们可以下面的特性来区分lfs:&nbsp;<BR>&nbsp;<BR>log&nbsp;什麽东西?&nbsp;data,&nbsp;metadata都log,&nbsp;或者是只记录meta-data.&nbsp;meta-data&nbsp;<BR>logging更可进一步决定是所有对档案属性的改变都记录起来,&nbsp;或者只记录影&nbsp;<BR>响档案系统结构的改变就好了.&nbsp;(time-stamps,&nbsp;ownership,&nbsp;permissions等要&nbsp;<BR>是当机时没改到基本上不会影响档案系统的完整)&nbsp;<BR>&nbsp;<BR>实作的方式是使用纯LFS(log-structured&nbsp;file&nbsp;system),另一者是用lfs&nbsp;<BR>的概念辅助FFS,改善crash的处理(log-enhanced&nbsp;file&nbsp;system).&nbsp;纯LFS需&nbsp;<BR>要full&nbsp;data&nbsp;logging,&nbsp;辅助性lfs通常就是mata-data&nbsp;logging而已.&nbsp;<BR>&nbsp;<BR>crash&nbsp;recovery方法也有两种,&nbsp;一种是redo-only&nbsp;log,另外一种是undo-redo.&nbsp;<BR>redo-only&nbsp;log在&nbsp;crash後把残馀的log继续做完.&nbsp;undo-redo&nbsp;log则可以选择&nbsp;<BR>redo或undo.不同点差在crash&nbsp;後的处理.&nbsp;redo-only较省disk&nbsp;space,&nbsp;<BR>但是crash&nbsp;recovery有较多synchronization&nbsp;的问题会出现.&nbsp;undo-redo&nbsp;<BR>的方式有较多的的优点,有synchronization&nbsp;问题的地方可以把档案还原.&nbsp;<BR>既然要undo,就会记录档案原来的资料,&nbsp;当然较浪费空间.&nbsp;<BR>&nbsp;<BR>本章讨论的两个lfs,&nbsp;4.4BSD&nbsp;LFS和&nbsp;Episode&nbsp;File&nbsp;System&nbsp;(by&nbsp;<BR>Transarc,由AFS衍生出来).&nbsp;Episode是OSF&nbsp;DCE标准采用的local&nbsp;<BR>file&nbsp;system,&nbsp;是DFS的基础.&nbsp;4.4BSD&nbsp;LFS是根据Sprite作业系统&nbsp;<BR>的研究而来的.&nbsp;LFS使用redo-only&nbsp;log.&nbsp;Episode使用redo-undo&nbsp;log.&nbsp;<BR>&nbsp;<BR>对LFS还是搞不清楚什麽是append&nbsp;only&nbsp;log?&nbsp;没关系,&nbsp;看了4.4BSD&nbsp;LFS後就了解了.&nbsp;<BR>Figure&nbsp;11-2一目了然.&nbsp;LFS基本上把DISK当成是一条磁带,每个block大小为0.5&nbsp;MB.&nbsp;<BR>一个block在disk上是一段连续的空间,&nbsp;不过相邻的(logically..)&nbsp;block则没有在&nbsp;<BR>disk上相邻,&nbsp;而是用list的方式相邻.&nbsp;用程式表示如下:&nbsp;<BR>&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;struct&nbsp;log_segment&nbsp;{&nbsp;&nbsp;&nbsp;&nbsp;/*&nbsp;block在LFS的术语里面叫log&nbsp;segment&nbsp;*/&nbsp;<BR>&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;int&nbsp;next;&nbsp;&nbsp;&nbsp;&nbsp;/*&nbsp;下一个log_segment&nbsp;所在的位址&nbsp;*/&nbsp;<BR>&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;char&nbsp;data[0.5MB-sizeof(int)];&nbsp;<BR>&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;};&nbsp;<BR>&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;而FFS则是在disk上以渐进的方式动态配置新的log&nbsp;segment以记录log.&nbsp;&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;segment间以linked&nbsp;list的方式串在一起.&nbsp;<BR>&nbsp;<BR>Kernel记录的log就是这样子记录到disk上的.&nbsp;在这个segment&nbsp;chain&nbsp;<BR>的tail才是整个档案系统的最新资料.不过旧的资料也没有被盖掉就是了.&nbsp;<BR>&nbsp;<BR>LFS还有一个机制,&nbsp;类似garbagge&nbsp;collection,&nbsp;更像defragementation.&nbsp;<BR>它使用一个cleaner&nbsp;process来清理旧的log.&nbsp;这个process会固定的把旧&nbsp;<BR>的log独出来(以segment为单位).然後他会将这个segment的内容与实际&nbsp;<BR>的资料比对,要是这个segment内的资料都是没有用的资料(已被新的资料&nbsp;<BR>所取代了)那麽cleaner&nbsp;process就可以把此segment&nbsp;free掉.&nbsp;如果segment&nbsp;<BR>还有一点东西,&nbsp;怎麽办?&nbsp;简单!&nbsp;重写一次,append到最新的log去就好了&nbsp;<BR>嘛(感觉好像nu的speed&nbsp;disk&nbsp;:).&nbsp;<BR>&nbsp;<BR>LFS仍然维持directory和inode的架构,&nbsp;只不过以前的inode是固定&nbsp;<BR>在disk&nbsp;blocks的最前端,而现在inode则是分散各地,存在各log&nbsp;&nbsp;<BR>segment里面.&nbsp;这样子怎麽读这个file&nbsp;system呢?&nbsp;LFS还有一个&nbsp;<BR>inode&nbsp;map,&nbsp;记录所有inode的位置.&nbsp;inode&nbsp;map被当成是一般的&nbsp;<BR>data一般,也是定期会写到log里面去.&nbsp;kernel就是靠此inode&nbsp;map&nbsp;<BR>作为读取这个档案系统的开端.&nbsp;<BR>&nbsp;<BR>大家最感兴趣的,&nbsp;应该还是效率问题了.&nbsp;首先LFS需要消耗更为大量&nbsp;<BR>的记忆体才能满足他的运作所需,&nbsp;有时候是个缺点.&nbsp;与FFS比较的结&nbsp;<BR>果在大部份的状况下都胜过FFS,&nbsp;除了在高度多工的时候稍微输了一&nbsp;<BR>点.&nbsp;Sun-FFS&nbsp;(有file&nbsp;system&nbsp;clustering和一些小地方的改进)和&nbsp;<BR>LFS比就不相上下了.&nbsp;BSD&nbsp;LFS在处理meta-data方面较Sun-FFS强(create,&nbsp;<BR>remove,&nbsp;mkdir,rmdir....).&nbsp;但在read/write等io集中的测试中&nbsp;Sun&nbsp;<BR>FFS则较快,&nbsp;特别是LFS&nbsp;cleaner启动的情况下更是如此.&nbsp;显然&nbsp;<BR>clustering发挥了不少功效.&nbsp;<BR>&nbsp;<BR>这边你要谨记在心的是LFS在metadata处理会赢过FFS,&nbsp;是因为写入&nbsp;<BR>动作较有效率的原因(sequential&nbsp;write),&nbsp;前面已经提到file&nbsp;system&nbsp;<BR>的瓶颈在write...&nbsp;<BR>&nbsp;<BR>Sun&nbsp;FFS和BSD&nbsp;LFS在模拟实际状况的bench&nbsp;mark上的平均分数是&nbsp;<BR>差不多的.&nbsp;LFS比FFS占优势的地方大概是快速的复原能力吧!&nbsp;<BR>&nbsp;<BR>本节引用了几份测试报告和bench&nbsp;mark,&nbsp;有兴趣的可以看参考书目,&nbsp;<BR>看人家如何评量一个档案系统的效能.&nbsp;<BR>&nbsp;<BR>本节提到另一个有趣的产品,&nbsp;Write-Anywhere&nbsp;File&nbsp;Layout&nbsp;(WAFL)&nbsp;<BR>system,&nbsp;是一家名为&nbsp;Network&nbsp;Appliance&nbsp;Corporation&nbsp;的&nbsp;FAServer&nbsp;<BR>系列的NFS产品.&nbsp;WAFL整合了log-structured&nbsp;file&nbsp;system,&nbsp;NVRAM&nbsp;&nbsp;<BR>(non-volatile&nbsp;ram,&nbsp;像PC&nbsp;cmos的咚咚),和RAID-4磁碟阵列,&nbsp;提供了&nbsp;<BR>高速的NFS&nbsp;response&nbsp;time.&nbsp;WAFL&nbsp;有一个特色是许多系统管里者有兴&nbsp;<BR>趣的,&nbsp;就是snapshot.&nbsp;snapshot就是备份的意思嘛!&nbsp;也就是系统某一时间&nbsp;<BR>的状态.&nbsp;snapshot在log-structured&nbsp;file&nbsp;system下应该不难制作,&nbsp;<BR>因为所有的资料都用append模式嘛..把cleaner&nbsp;process的功能作个&nbsp;<BR>修改就是了.&nbsp;snapshot&nbsp;优於传统的备份的原因应该很明显,&nbsp;传统的&nbsp;<BR>备份过程必须花上一段时间,系统在这段时间内若有修改的话,&nbsp;这段&nbsp;<BR>时间内的修改则不知道有没有备份到.而snapshot则可以像照相一般&nbsp;<BR>得到系统瞬间的备份.使用者也可以利用snapshot取得旧的档案内容&nbsp;<BR>或达到undelete的功能.&nbsp;<BR>&nbsp;<BR>由LFS和Sun-FFS的比较可以了解meta-data&nbsp;logging(log-enhanced&nbsp;&nbsp;<BR>file&nbsp;system)存在的原因了,&nbsp;取长补短嘛.&nbsp;本章也讨论了meta-data&nbsp;<BR>logging的系统.&nbsp;meta-data&nbsp;logging在商品化的系统上较受欢迎,&nbsp;<BR>成为市场主流,&nbsp;因为他可以架构在FFS上,改变不会太大,&nbsp;还可以和&nbsp;<BR>对FFS的改进(如clustering)互相配合,相得益彰.&nbsp;<BR>&nbsp;<BR>本章讨论的另一个lfs是Transarc的Episode&nbsp;File&nbsp;System.&nbsp;Episode&nbsp;<BR>采用redo-undo&nbsp;metadata&nbsp;logging,&nbsp;并且他的file&nbsp;system可以横越&nbsp;<BR>好几个硬碟.&nbsp;Episode也提供了类似snapshot的功能,&nbsp;称为cloning.&nbsp;<BR>cloning使用copy-on-write的技术,只复制anode&nbsp;(Episode的inode).&nbsp;<BR>Episode在security方面也提供了POSIX式的access-control&nbsp;list&nbsp;(ACL),&nbsp;<BR>提供较传统Unix更为精细的档案属性控制.&nbsp;<BR>&nbsp;<BR>
12 3 下一页
⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -