http://fedoraproject.org/wiki/Extras/MockTricks
Using tmpfs to avoid disk access
It's not clear that tmpfs is a huge win anymore, now that autocache works and is a standard feature.
When having enough RAM (1.5-2 GB), using a tmpfs can speedup the 'prep' phase significantly. With 1.5GB RAM on a Celeron 2.8 GHz, populating the buildroot will take 2-5s (seconds) on subsequent builds.
You can either mount /var/lib/mock as a tmpfs, or you can mount each of the build directories under /var/lib/mock as separate tmpfs file systems. The latter lets you use the autocache above and keeps the autocache files on disk, rather than in the tmpfs. If you erase and recreate the autocaches often, keeping them in tmpfs makes sense. If you don't recreate them often, then you should use per-build-directory tmpfs mounts instead.
可惜我只有 1 GB 内存。刚装好的 build root 大概有 220M，解压之后是 580M，就提示内存不足了。买内存吧。不然每次解压 root 实在是太慢了。mock 真是一个过于重量级的系统。
是不是应该把 squid cache 调整到 2 GB 呢。
mock *.src.rpm 可以一次编译出所有软件包，不过这样就没办法检验 build requires 了，那才是主要目的。今天回去试下 for i in *.src.rpm; do mock $i; copy build.log .... 大概就是这样子。还有，这样做是没办法控制编译顺序的，那么依赖关系怎么办？ybui
update：
突然想到，FE 之所以采用 Makefile 的方式，应该也是为了解决编译顺序问题。
坦白地说，工作时间，在利用公司网络玩，并且读一些与工作内容无关的文档，真是太TM
