基于TILERA的论文，对FOS进行了初步的学习和分析

1. TileraFOS分布式操作系统的实现 sibeliuscn@gmail.com http://t.sina.com.cn/1642083541

3. MIT 计算科学和人工智能实验室 的 两位教授 Jason Miller 和Anantagarwal（后者同时也是tilera的CTO）在其论文“an operating system for multicore and clouds: mechanisms and implementation”中提出FOS。

4. http://groups.csail.mit.edu/carbon/docs/socc_2010_sub.pdf

5. ACM 上也有该篇文章的链接 http://portal.acm.org/citation.cfm?id=1807132

8. Namespace (API 内部的LB，程序员透明)

9. OS services 操作系统服务，而不是调用

10. Messages 基于消息

11. Parallera data-structure （并行的数据结构）

12. FOS server 设计原则： Time multiplex vs space multiplex （通常SMP系统，任务调度器在一个物理机上的不同的core间进行任务（进程）调度，分配的资源是CPU的time slice ； 与这对照的，FOS是在name service 中进行调度，调度的资源是spatially-distributed 的多个core上运行的OS SERVICE） OS factor as function-specific services（系统服务按照分布式，并行的原则实现 。应用通过libfos，以消息的方式去申请资源 。我的理解： 通常OS 实现的资源管理，以系统常规调用去激活例程（routine）; 而在FOS中间，文件访问，内存申请等等均是通过service 来实现） OS adaptor resource utilizing （服务的利用率是被衡量的，OS 在分布式的环境中间） Fault avoid （spawn to build a fleet and recycle）： OS 会探测到故障并据此进行相应的调度。 9/30/2010

14. 微内核的出现是基于这样一些考虑（代码较小导致的轻量化带来灵活性，更加重要的是，分布式计算其实并不需要全功能的内核）

15. OS 和kernel的关系，在我们熟悉的情况下是1:1 ； 而在FOS下，是1:X (tilera目前是64~128，明年是1024吗？)

16. 微内核的组成：Protected message layer Name cache for performance purpose 基本的时间片复用管理 (一个core 仍然可能运行多个线程，例如一个FileSystemrequest 和由自己申请的FS call) API （仅仅实现内存地址空间申请和线程的创建，特别是其设计为可以以一种异地内存访问的形式工作，例如：运行在core-A上的进程可以对core-B上异地内存的进行修改操作（原文为Modify）。。。Maybe Numa？） 9/30/2010

19. 某一特定的OS服务由分布在不同machines上的多个进程组成。（name server 将依据一些策略选择最适合的服务进程来提供某一次的service request ）

20. 每个进程创建的时候会得到命名，并且将该名字关联在上一页我们提到过的mailbox上….

21. 所谓的名字具备URI的形式，这样的抽象化带来的好处是灵活性和进行LB时候的本地化局部亲和性。。。（）论文中也谈到，命名空间还有这样一些需要完善的地方，如： 进行调度的策略（目前有RR, core的亲和性，队列长度） 和所有其他一些命名服务（GFS name, HDFS…）相似的，naming service 需要 解决的是在提供名称服务时既能够保证低延迟又能保证一致性。例如，如果某个提供 service 的core需要离开或者加入的时候去保证namespace的update。 论文认为目前在P2P应用中间应用广泛的DHT（分布式哈希表）应该能够成为一个好 的解决办法。（听起来时候再FOS上暂时没有这么实现）。 西贝流士按：这样设计的好处是，某个core offline的几率要比SMP结构下共享cache 条 dirty的几率 小，所以效果要好使应该的，而且，DHT也已经被证明其简单和高效了 西贝流士按：具体的细节论文中间没有再详述，我们不妨可以想象： 基于文件服务的命名也许是这样： nameURI.Filesystem.ext3.server001.core001./var/log/DEMOlog -- 标识了一个运行在machine001上第001core上的一个命名服务进程，而如果name server 觉得这台服务器lwork load 不高的话，应该就会优先将该请求进程申请的文件调用仍然放回到本地服务器上去，从而满足本地亲和性的原则。 9/30/2010

23. FOS 将通常的OS service 抽象为由一组运行在不同machine上的进程组成（称为Fleet），这些进程是位置上分布的（spatially-distrbuted）， 但却是通过之前提到的messages 进行协作。

24. 某一特定的OS服务由分布在不同machines上的多个进程组成。（name server 将依据一些策略选择最适合的服务进程来提供某一次的service request ）

26. 而接受message的mailbox有3级:

27. 右图呈现了mBOX的设计，而且显然是以非阻塞方式处理External mailbox （新进request） Internal mailbox (处理fleet内部的messages) Response mailbox （处理pending的request) 西贝流士：在人们已经熟悉了epoll/libevent/libV等事件通知模型以后，OS service server就可以理解为类似的实现，这已经被公认为高效而成熟的网络服务器并发模型了。 9/30/2010

28. FOS1学习 -12010 12-27 形象的描绘了一个典型的系统调用或者函数请求的过程，注意其中的几个角色： FOS server; proxy server, libc和其下层的libfos,唯一不清楚的是hypervisor的角色，在microkernel 之下？ 论文中没有提到！

29. FOS2 -1 多核计算环境 基于消息和OS 服务模型的分布式 一个physical layout ,挺好玩的 9/30/2010

30. FOS2-2 满足POSIX 兼容？的fs调用过程 How to compliance with POSIX,其实太具体了，如果有，其实就是直接读代码。。 9/30/2010

31. FOS2 -3OS service server提供服务的过程 制作者：西贝流士 Sibeliuscn@gmail.com 注意3个mailbox 队列 External mailbox （新进request） Internal mailbox (处理fleet内部的messages) Response mailbox （处理pending的request) 9/30/2010