如何上好操作系统这门课？

作为一个年轻教师，在第一次备课的时候，我会向国内外著名的教授学习，去他们的主页找课件，看他们都会讲哪些topic，每个topic如何组织，各topic如何关联，课上问哪些问题，课后做哪些lab和homework，怎么出考卷，考哪些内容，等等。

在接下来几年的教学实践中，渐渐发现一些新的问题，比如：

• 内容难度上，过难可能会打击学生积极性，过简单则导致教学失去意义；
• 对于同样的内容，有些学生听不懂，有些却早就自学过，再听觉得没意思；
• 有些概念，仅仅讲原理觉得太虚，讲具体实现却又觉得不够通用；
• 有些知识点，学生上课时往往觉得自己听懂了，可遇到实际问题却完全不能应用；

这些问题如何解决？不幸的是，这次Google没法找到答案，唯一的方法只有不断摸索，积极尝试，获取反馈，修正后再尝试…然后不断迭代，一点点改进。

试想，如果可以直接与国内外最顶尖的教授们当面讨论这些问题，那该多好！

所以，当我得知Corenell大学的Robbert Van Renesse和UCSD的Geoffrey M. Voelker两位计算机系统界的知名教授受MSRA的邀请来中国专门为计算机系统教学举办为期三天的Workshop时，果断报名参加——这是我第二次参加这个Workshop，尽管如此，我的收获还是远远超过了预期。

This is a question confused me for a long time. The answer was “no” for a long time, but became “yes” nowadays. Take Ubuntu as an example, before 12.10, the answer was “no”; from 12.10 on, the answer becomes “yes”. We’ll track the change of fsync’s man page to see the details.

Change of fsync()

First, let’s see the The Open Group Base Specifications Issue 6, IEEE Std 1003.1, 2004 Edition. This is POSIX.

TL;DR

Disk write buffer will violate user’s assumptions on durability (e.g., ATM transaction lost on power failure) and write order (e.g., journal COMMIT before the transaction has actually done).

What is disk write buffer

Disk write buffer is a small amount of memory embedded in a disk drive. Once a disk receives a write operation, it can signal the invoker “write done” as long as the data is written on the buffer instead of on the platter. Thus, there’s a time window between the “claimed done” and the “actual done”. In this way, the invoker can move forward instead of waiting for a long time, since writing to platter is much slower. Another benefit is that the disk can merge and re-order disk writes within the buffer to reduce unnecessary disk header movement and improve the performance. Experiment shows that for some scenarios, the write buffer can improve disk write performance by an order of magnitude.

System Performance Analysis

As stated by Andy Hunt in his book Pragmatic Thinking and Learning, the most significant difference between a newbie programmer and an expert is the abilibity to sense the context of a problem while solving it. What a newbie needs is only a list of step-by-step operations which are context independent, while an expert has to know details as many as possible. Thus, as an expert of system performance analyzing and tuning, you need to use tools such as vmstat and iostat to get details. In order to be such an expert, you need a step-by-step guide.

Here is the guide.

For last two weeks I’ve been doing some experiments on Xen and HVM. I found that the TOCTTOR, short for Time of Coding To Time of Result, is too long, which is really annoying and disrupting. I tried to shrink the time and now I have successfully shrink the time to less than 30s on my 2010 MBP (with SSD). Here is how.

1. Using VMware for Testing

Yes, it is fast enough. VMware does a great job on performance improvement these years. Using it can significantly reduce the time of rebooting, from more than 60s to about 10s.

A good news is that VMware now supports EPT emulation, so I can run Xen on VMware, and run HVM on Xen. It also supports virtual serial port, which is essential for Xen debugging.

2. Using rsync for Compiling

I edit and compile the source code on another machine with powerful CPUs, and rsync the binary to VMware for testing. The compiling time is not long since I only modify a small part of Xen. The compiling and rsyncing take about another 10s.

Another benifit of using rsync is that you can keep reading and modifying the code when rebooting the test environment in VMware. It’s another kind of parallelization.