|
|
|
|
  多线程文件系统 - zhangxp [ 2005-04-12 20:48 | 509 byte(s)]
Re: 多线程文件系统 - banyan [ 2005-04-20 11:32 | 289 byte(s)]
Re: 多线程文件系统 - zhangxp [ 2005-04-20 23:47 | 221 byte(s)]
Re: 多线程文件系统 - banyan [ 2005-04-21 16:58 | 1,192 byte(s)]
Re: 多线程文件系统 - ffxz [ 2005-04-21 17:54 | 651 byte(s)]
Re: 多线程文件系统 - ffxz [ 2005-04-28 10:21 | 1,302 byte(s)]
Re: 多线程文件系统 - kgon [ 2005-04-28 10:44 | 50 byte(s)]
Re: 多线程文件系统 - zhangxp [ 2005-05-19 08:51 | 16 byte(s)]
Re: 多线程文件系统 - yftty [ 2005-07-02 22:39 | 205 byte(s)]
Re: 多线程文件系统 - kgon [ 2005-04-22 21:15 | 414 byte(s)]
Re: 多线程文件系统 - banyan [ 2005-04-23 11:52 | 1,194 byte(s)]
Re: 多线程文件系统 - kgon [ 2005-04-23 12:44 | 705 byte(s)]
Re: 多线程文件系统 - banyan [ 2005-04-23 20:53 | 493 byte(s)]
Re: 多线程文件系统 - kgon [ 2005-04-24 08:13 | 495 byte(s)]
Re: 多线程文件系统 - banyan [ 2005-04-24 12:00 | 597 byte(s)]
Re: 多线程文件系统 - kgon [ 2005-04-24 12:36 | 1,826 byte(s)]
Re: 多线程文件系统 - banyan [ 2005-04-26 16:51 | 3,075 byte(s)]
Re: 多线程文件系统 - kgon [ 2005-04-26 18:13 | 1,038 byte(s)]
Re: 多线程文件系统 - banyan [ 2005-04-22 11:09 | 1,470 byte(s)]
Re: 多线程文件系统 - zhangxp [ 2005-04-20 19:04 | 139 byte(s)]
|
|
|
|
[Original]
[Print]
[Top]
|
我看linux与安德鲁的那场争论中多次提到了“多线程文件系统”，
是不是这个意思：文件系统部分的内核代码可并发执行，比如系统调用read没有执行完，并且也没有阻塞，被其另一程序抢占，又可以在该程序中执行read。
可是感觉又不对，这应该叫内核可抢占吧？
不太肯定是什么意思。也没搜到这方面的文章，请指点一二，或给我些相关的文章。
非常感谢。
|
|
----
弃我去者昨日之日不可留，乱我心者今日之日多烦忧！
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
linus vs. akpm? 能否给个链接看看，我猜可能是有关异步VFS接口的讨论。目前Linux核心支持异步I/O，但元数据操作都还是串行进行（有一些并行化的patch，比如对大目录的共享并发存取等），因此当单个单个目录中包含的文件数量越来越多时，并行化VFS接口对提高性能是有必要的，这的确不是一个简单问题。
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
我没有链接，是丛书上看到的。。
《开源软件文件》最后附了那些讨论，这本书很便宜了，，china-pub上10块钱不到了！！
|
|
----
弃我去者昨日之日不可留，乱我心者今日之日多烦忧！
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
好像跟“异步VFS接口”没什么联系，，我记得有一句：
“多线程文件系统对微内核是个黑客行为，是对性能的修修补补，但对于整体内核确实自然而然的功能”
linux说的。。linux没有这个概念吗》？？？
|
|
----
弃我去者昨日之日不可留，乱我心者今日之日多烦忧！
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
目前对文件元数据的系统调用都是同步（同步vs异步，串行vs并行）的，比如某个进程需要对在一个包含同一个目录里的两个不同文件同时执行stat系统调用时，它必须这样：
rc = stat("A", buf1);
/* wait the 1st stat finish */
rc2 = stat("B", buf2);
其异步形式则类似于这样：
rc = stat("A", buf1);
/* 无需等待其结束 */
rc2 = stat("B", buf2)
/* 无需等待其结束 */
wait_stat_finish();
这种形式与文件read/write的asynchorous I/O类似。当多个进程对大型目录（比如一个包含1百万个小文件的目录）发出类似的元数据系统调用时，这种异步的实现可以提高整个系统聚集吞吐率（Aggragate Throughput）。
Linus之所以那样评论，原因也很简单，因为绝大多数用户根本不会觉得这种特性有什么特别的好处，而只是一种Hack。但是现实中的确存在一些应用，它们需要这种机制的支持来最优化吞吐率性能。
如果想研究文件系统，最好是去亲自动手分析代码，另外多做些试验。另外，Hans 在Namesys网站上推荐的那些paper也值得一读（至少比10块钱不到的书好的多  ）。
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
linux能做到这个吗，记得大多文件系统实现都是这样，
xxfs_stat()
{
lock_volumn
...
unlock_volumn
return;
}
形式的
呵呵，能否探讨些RT Filesystem的东西呢？！
RT系统中假设是全抢占的，可能read到一半时被切到另一个任务，另一个任务再做read，
那么read必须加保护(semaphore, lock etc)，要异步、并发难啊(加锁的粒度太大了)
引入Filesystem Server（大体上相当于微内核结构），所有请求都发到Filesystem Server Task，Filesystem Server Task串行读取请求
但这个效率……好处是，可以引入优先级的概念，优先级高的可以先服务
|
|
----
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
现在的Linux核心当然没有这种支持，但是我的确看到过一些Proposal，呵呵 
你所说的那种类似micro-kernel FS server的做法应当是可行的。其实FS派生出来的I/O请求队列与Block Device I/O调度器就可以视为一种C/S结构的实现。通过合并多个相容的FS metadata syscall，OS可以减少Disk访问，提高 throughput。
文件系统的QoS是一个有趣的题目，当然包括它的RT特性。据我所知，目前这方面相关研究还不多见。个人认为主要原因可能还是因为在一般的OS中，基于Disk（network fs的情况类似）的FS与Block Device Driver构成了一个层次结构，两者的RT特性是息息相关的，不大可能能够抛开Block Device的I/O scheduler的RT特性去直接讨论FS的RT特性。同时具备RT特性的Block Device Driver必须能够理解FS所在Disk的静态（平均寻道时间、旋转延迟等）与动态（磁头位置、On-Disk-Cache命中率等）物理特性与行为，否则此Block Device Driver不可能具备RT特性，更不用说FS了。不过关于Disk动态模型抽取方面，我看到过一些论文声称其算法能获得比较准确的抽象模型，但没见哪儿用过 现在Object Disk的出现可能在一定程度上更好地支持QoS与RT特性，因为Object Disk内嵌软件的功能比现在磁盘控制Firmware肯定要强大的多，完全有理由相信它还能理解上述那些今天我们需要绞尽脑汁才可能能弄到的那些磁盘静态与动态参数。
呵呵，乱说一气，欢迎拍砖
|
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
不管是用filesystem server还是把filesystem放到kernel里面,问题的本质没有变.都是引入了更细粒度的concurrent system,以前的系统处理请求其实都是串行的,唯一要考虑的就是优先级较高的irq,所以比较简单,现在对请求都并行处理以后(也就是抢占),就需要考虑到系统的一致性等问题,解决这种问题就是让他们对所有共享的数据结构的访问有一个一致的顺序,比如用timestamp,或two-phase lock等
如果还要引入优先级,还得防止优先级翻转
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
>不管是用filesystem server还是把filesystem放到kernel里面,问题的本质没有变.都是引入了更细粒度的>concurrent system,以前的系统处理请求其实都是串行的,唯一要考虑的就是优先级较高的irq,所以比较简
有些I/O接口协议，如SCSI，是能够支持所谓多线程I/O的（通过DISCONNECT-RECONNECT命令），主机驱动同时可以发出多个访问DISK的命令（这个过程有点类似于超标量处理器多条指令发射的场景，这多条命令间从逻辑应该是可并发执行的，这点应由驱动程序来保证）而无需等一个命令执行完后再发下一条命令（象ATA/IDE命令集一样）。
另外对文件系统而言，底层块设备的I/O请求执行过程对它是透明的，跟硬件中断并没有直接关系。
>单,现在对请求都并行处理以后(也就是抢占),就需要考虑到系统的一致性等问题,解决这种问题就是让他们>对所有共享的数据结构的访问有一个一致的顺序,比如用timestamp,或two-phase lock等
>如果还要引入优先级,还得防止优先级翻转
我的理解是：与处理器设计中的Weak Consistency内存模型上取得较好的性能与正确执行结果的方法类似，细粒度化并行化文件系统元数据访问接口最好由OS与新的用户级API一起来实现，单靠OS完成所有工作（对程序员透明）的做法并不是个好办法，因为它可能会过于复杂。
|
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
那要看怎么抽象了,如果把disk manage当作文件系统的一部分,用户进程和cpu都是client,系统调用和irq中断请求都是client请求,irq中断处理是高优先级的请求
>>>>>我的理解是：与处理器设计中的Weak Consistency内存模型上取得较好的性能与正确执行结果的方法类似，细粒度化并行化文件系统元数据访问接口最好由OS与新的用户级API一起来实现，单靠OS完成所有工作（对程序员透明）的做法并不是个好办法，因为它可能会过于复杂。
如果对操作系统实行weak consist model,那么对应用程序员的要求就非常高,为了降低应用程序员的要求,那么这部分难度会转移到language system里面,这也不容易,而且不容易实现操作系统的透明化.我觉得这个还要看系统要求,在性能和易用性间找到一个平衡
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
>如果对操作系统实行weak consist model,那么对应用程序员的要求就非常高,为了降低应用程序员的要
NFS就是典型的弱语义文件系统，是程序员基于它写程序也有一二十年了。
>求,那么这部分难度会转移到language system里面,这也不容易,而且不容易实现操作系统的透明化.我觉
>得这个还要看系统要求,在性能和易用性间找到一个平衡
完全同意这个观点，不可能有一个十全十美的解决方案，在新的环境里，设计者需要寻找的是最优的tradeoff，呵呵
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
>>NFS就是典型的弱语义文件系统,是程序员基于它写程序也有一二十年了
它的datastore支持release consist model,但它给程序员的接口仍然是sequence consist的,比如open一个文件的时候,就会创建一个cache,以后读写的时候,只是在这个cache里面操作,最后close文件的时候,才把这些修改传播出去,保证系统的consist,所以我觉得对于程序员来讲,整个nfs系统仍然是sequence consist的,不知道我这样理解对不对
好像现在很多datastore系统都有采用weak consist model 的趋势,比如ia64的register file,
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
程序员在NFS上编程时，他是应该意识到底下是一个Weak Consistency的FS。对于一个并行程序中位于不同客户节点上的两个协作进程，当它们需要对NFS中共享普通文件或目录进行R/W操作时，如果程序本身的运行结果依赖于顺序一致性语义，则程序员必须对程序进行适当的修改以保证程序的正确执行。
非UNIX语义的文件系统有很多种，如许多一些Replicated FS上View consistency，IBM Storagetank上的Publish consistency等等；现在在Internet Cache（或者叫Content Delivery Network）与P2P系统中用到的都是一些放宽的共享语义，以便在性能与编程模型上获得较好的平衡。但是UNIX语义独一无二的好处就是编程简单。
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
>>程序员在NFS上编程时，他是应该意识到底下是一个Weak Consistency的FS。对于一个并行程序中位于不同客户节点上的两个协作进程，当它们需要对NFS中共享普通文件或目录进行R/W操作时，如果程序本身的运行结果依赖于顺序一致性语义，则程序员必须对程序进行适当的修改以保证程序的正确执行。
我没有nfs下编程的经验,我是根据一些理论加上简单的nfs的介绍来进行一些猜测,有不对的地方还请一定指正.
举个例子:
假如系统中存在一个文件的几分拷贝,不做任何同步的两个进程分别别对它写"1","2",写完后,如果系统中同时存在内容为"1","2"的两份拷贝,我觉得这个就是weak consist的文件系统,程序员要想保证系统的consist,就需要额外执行一个同步操作(由文件系统提供),使系统中要么存在一个全是"1"的拷贝,要么全是"2"的拷贝
如果文件系统本身就保证了sequence consist,那么程序员就不用做这个额外同步操作,就能保证系统只存在一个相同的拷贝,要么是1,要么是2.
假如nfs是我上一篇帖子那样,我觉得系统肯定只存在一个相同的拷贝,所以,nfs对于程序员应该是sequence consist的.如果假如你表达的"运行结果"是想让系统中存在内容为"12"或"21"的拷贝,我觉得这个属于同步范畴,而不属于系统consistency的范畴
另外,我觉得对系统对consist语义的放松主要是针对request间同步的放松.比如最strict 的strict model(也就是unix model),所有request全部用timestamp同步
再relax一点的sequence consist模型,系统对每一个请求都做同步,不同进程的request做mutex,相同进程的做condition sync,再弱一点的
再relax一点的causal model, 只对有依赖关系的request做condition sync.
依次类推,到weak consist,系统不再对request进行同步处理,所有的request可以并行进行,但系统一般提供了同步原语用于保证系统的consist,程序员对系统进行读写的时候,如果需要保证系统是consist的,就需要自己来实现各个request间的同步.
|
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
>我没有nfs下编程的经验,我是根据一些理论加上简单的nfs的介绍来进行一些猜测,有不对的地方还请一定指正.
呵呵，客气
>举个例子:
>假如系统中存在一个文件的几分拷贝,不做任何同步的两个进程分别别对它写"1","2",写完后,如果系统中同时存在内容为"1","2"的两份拷贝,>我觉得这个就是weak consist的文件系统,程序员要想保证系统的consist,就需要额外执行一个同步操作(由文件系统提供),使系统中要么存在>一个全是"1"的拷贝,要么全是"2"的拷贝
对于Non-Replicated，就是只包含唯一磁盘文件副本的文件系统，如果它不是一个分布文件系统，就不会出现你上面说的两个副本的情况。
所谓UNIX文件语义指：一个进程对文件的写可立即对其它进程可见。对于UNIX下的单机文件系统，这个是没有问题的，因为文件数据都在OS的PageCache里头，在UNIX文件存取上有句经典的话“Last Writer Will Win”，就是指文件的最终内容由最后一个文件执行写操作决定。而采取非UNIX语义的文件系统，一般都是网络文件系统，如NFS、AFS等，但是也有很多实现UNIX语义的网络文件系统，如Lustre、GPFS、Frangipani等，一般它们都通过复杂的锁协议来支持UNIX语义。NFS在支持客户端Cache的情况下，是采用的一种基于超时的机制，它假定在一段时间内，它缓存的数据是有效的，因此对于一个RAW操作，R有可能看到的是旧数据——因为其它客户节点有可能对相同数据执行了写操作。
>如果文件系统本身就保证了sequence consist,那么程序员就不用做这个额外同步操作,就能保证系统只存在一个相同的拷贝,要么是1,要么是2.
>假如nfs是我上一篇帖子那样,我觉得系统肯定只存在一个相同的拷贝,所以,nfs对于程序员应该是sequence consist的.如果假如你表达的"运>>行结果"是想让系统中存在内容为"12"或"21"的拷贝,我觉得这个属于同步范畴,而不属于系统consistency的范畴
如D.Patterson在量化分析所指出，同步机制是实现某种consistency模型的经典方法。在文件系统层次上与之也相类似，如Lustre、GPFS等都是通过内嵌在R/W操作中的锁（非lockf/flock锁）来实现UNIX语义。这种锁与文件锁的区别在于：它们可以被另一个竞争的进程所剥夺。
>另外,我觉得对系统对consist语义的放松主要是针对request间同步的放松.比如最strict 的strict model(也就是unix model),所有request>>全部用timestamp同步
>再relax一点的sequence consist模型,系统对每一个请求都做同步,不同进程的request做mutex,相同进程的做condition sync,再弱一点的
>再relax一点的causal model, 只对有依赖关系的request做condition sync.
呵呵，这个与前几年我的文章中的想法近似（在UCB P2P结构的OceanStore中也有类似Idea），现在看来可以还可以进一步细分：我们甚至能对不同用户实施不同的策略，这也可以看成是文件系统QoS的一部分，不过对于已经习惯了UNIX文件语义的程序员，可能很难接受这些feature
>依次类推,到weak consist,系统不再对request进行同步处理,所有的request可以并行进行,但系统一般提供了同步原语用于保证系统的consis>t,程序员对系统进行读写的时候,如果需要保证系统是consist的,就需要自己来实现各个request间的同步.
|
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
>>如果它不是一个分布文件系统，就不会出现你上面说的两个副本的情况。
对,centric的文件系统本身就可以很自然的实现sequence consist或strict consist(unix consist), 我举的例子是文件系统有多个点可以同时读写的情况]
>>>NFS在支持客户端Cache的情况下，是采用的一种基于超时的机制，它假定在一段时间内，它缓存的数据是有效的，因此对于一个RAW操作，R有可能看到的是旧数据——因为其它客户节点有可能对相同数据执行了写操作。
照这种描述的话,nfs的确应该算是weak consistency,程序员如果要读取某些文件,如果想保证自己读到的是consist的值,首先应该对文件系统做一下同步,让自己需要读取的值先成为consist的.
>>>如D.Patterson在量化分析所指出，同步机制是实现某种consistency模型的经典方法。在文件系统层次上与之也相类似，
从consistency模型的实现角度来讲,我觉得consistency应该包含同步和copy的传播两个方面.这种问题也许用object system描述更恰当些,不管object是文件还是memory location还是register files,问题的本质都不会变
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
说说我的理解
做为一个RT环境，各个方面都是很重要的，其中的一个部件缺少了RT特性就有可能导致整体的RT性能
对于文件系统，大致可以分成几层:
文件系统管理层(like VFS)
文件系统(like EXT3, NFS, SmbFS etc)
设备驱动(like IDE, SCSI etc)
而对于分布式文件系统来说，由于网络的不确定性，已经没什么RT特性可言了
至于说文件系统的QoS，这要依赖于下层的设备驱动。我所说的RT filesystem主要指的还是上两层，不过只能说意义不大，特别对于一个通用型的文件系统/文件系统管理层来说更加如此。
嗯，我一直有这么一个思考：
能否对每个层次都抽象成一个任务（为什么是任务？因为任务比较容易实现独立的全抢占，优先级调度，以及对系统数据结构的保护性也比较好），当一个用户的请求过来时将根据系统配置情况、用户访问的存储设备做相应的request forwarding，这样把对request的性能要求给转嫁到相应的层次上……也就是说，针对于NFS，由NFS来保证它的访问请求，然后NFS又转嫁给协议层（属于设备驱动层），由协议层来保证服务质量。
不过这样存在很大的问题，可能会导致任务频繁的切换（过度的任务切换带来了太多的上下文切换开销，对于数据吞吐量很难上去），另外就是cache的问题，这个cache到底应该放到哪一层会比较合适。
或许嵌入式系统中的KISS(Keep It a Simple System)原则更好些，这样上层的文件系统可以管理/控制/优化驱动层的操作。
|
|
|
----
|
|
[Original]
[Print]
[Top]
|
|
|
声明: 本页内容为中国Linux论坛的内容镜像，文章的版权以及其他所有的相关权利属于中国Linux论坛和相应文章的作者，如果转载，请注明文章来源及相关版权信息。