00000001.htm

一份很好的linux入门资料

NFS&nbsp;version&nbsp;3於1995年公布,更正了NFS&nbsp;v2的大部份的问题.&nbsp;(security&nbsp;<BR>
的问题是在RPC上面.&nbsp;RPC本来就有提供security的机制,只是少有实作而&nbsp;<BR>
已...)&nbsp;由於NFS&nbsp;v3出现蛮晚的,有支援的Unix可能算很赶的上流行了:)&nbsp;<BR>
&nbsp;<BR>
本章提到两个dedicated&nbsp;NFS&nbsp;server.&nbsp;我比较有兴趣的是Auspex&nbsp;NS5000.&nbsp;<BR>
另外一个是IBM的,&nbsp;focus在容错.&nbsp;Auspex&nbsp;NS5000有好几个CPU,&nbsp;每个CPU&nbsp;<BR>
都作单一个事,分成两组,一组处理网路上的需求,另一组处理硬碟档案系&nbsp;<BR>
统的IO.另外有一个CPU跑修改过的SunOS,admin用,其他的CPU都跑一个叫&nbsp;<BR>
做functional&nbsp;multiprocessing&nbsp;kenel&nbsp;(FMK)的系统,彼此间用message&nbsp;&nbsp;<BR>
passing交谈.&nbsp;FMK的好处是他只提供作NFS&nbsp;server所必要的function,&nbsp;&nbsp;<BR>
而不提供Unix的语意/环境,使得系统省下不少负担.&nbsp;<BR>
&nbsp;<BR>
RFS没什麽好提的...&nbsp;<BR>
&nbsp;<BR>
AFS,&nbsp;Andrew&nbsp;File&nbsp;System是CMU发展的系统,&nbsp;後来成立Transarc&nbsp;<BR>
Corporation.继续发展.&nbsp;後来AFS演变成OSF&nbsp;DCE的Distributed&nbsp;File&nbsp;<BR>
System.本书AFS/DFS都有详细的介绍.他们太复杂了,看书比较清楚.&nbsp;<BR>
结论是AFS比较不好,&nbsp;DFS作了很多改善,&nbsp;功能也比较多.&nbsp;DFS比较特&nbsp;<BR>
别的是对分散式档案系统cache的改进.&nbsp;DFS&nbsp;server会给他的client&nbsp;<BR>
一个(read/write/status/lock..)token,&nbsp;允许他(read/write/status&nbsp;<BR>
/lock..)等等的动作而不需要与server&nbsp;synchronize,也不用&nbsp;<BR>
update&nbsp;cache.也就是说该client拥有该资料的使用权(token,权杖之意).&nbsp;<BR>
client拥有token直到kernel撤回这样权力为止.kernel随时可撤回&nbsp;<BR>
这些token,表示有人要更改data,需要synchronize了.&nbsp;<BR>
&nbsp;<BR>
token的想法非常的高明,因为传统的方法所有的时间都要synchronize.但是&nbsp;<BR>
token的想法则是考虑到大部份的时间内皆不会产生race&nbsp;condition,所以&nbsp;<BR>
不需要每个动作都synchronize.&nbsp;<BR>
&nbsp;<BR>
不过文中也指出,&nbsp;DFS非常的复杂,&nbsp;不好实作就是了.&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>
要是你可以拦截使用者对某些目录的存取,然後偷天换日一下,&nbsp;那一定可以&nbsp;<BR>
让系统更有趣.&nbsp;比如说Mail来的时候通知使用者(不用一直polling),&nbsp;使用者&nbsp;<BR>
读某个档时就把目前时间印出来,&nbsp;使用者open&nbsp;/tcp/&lt;service&gt;/&lt;hostname&gt;时,&nbsp;<BR>
就产生对&lt;sevice:hostname&gt;的连线,让没有网路知觉的shell,awk程式也可以&nbsp;<BR>
轻松处理网路上的资料.&nbsp;<BR>
&nbsp;<BR>
本章讨论了两个这样的系统,第一个是watchdogs,这是学生的研究作品,&nbsp;<BR>
整合性不足.&nbsp;4.4&nbsp;BSD&nbsp;Portal&nbsp;file&nbsp;system才可以算完整解决方案.&nbsp;<BR>
&nbsp;<BR>
一个新的File&nbsp;System写起来很复杂,&nbsp;而一般人可能只想在file&nbsp;system&nbsp;<BR>
上加点小功能,比如说on-lin