/proc/mounts介绍

现在的 Linux 系统里一般都有这么三个文件：/etc/fstab，/etc/mtab，和 /proc/mounts，比较容易让人迷惑。简单解释一下。

/etc/fstab 是只读不写的，它提供的是系统上挂载设备的静态信息，比如 mount -a 就会挂载 /etc/fstab 里面指定的文件系统。

/etc/mtab 是供 mount/umount 进行读写的，是相对动态的。读的话，比如你在挂载一个文件系统时缺少一个参数，它就会自动去/etc/mtab 或者 /etc/fstab 里去查，如果找到的话，只要一个参数也够。写的话，比如你umount了一个文件系统，umount 就会删掉/etc/mtab 里面的相关记录。

看似上面的这两个文件已经够用了，但是新的情况出现了。Linux 内核引入了一个 mount namespace，是给container用的。因为这个的出现，Linux 不得不引入 /proc/mounts。为什么呢？因为记录 mount 信息的 /etc/mtab 是全局的，也就是说，就算你的某个进程有自己的 namespace，但只要还和外面共享同一个 /etc/mtab，那么，里面进行umount/mount操作的信息也会被记录到/etc/mtab里，外面也会看到！凌乱了！由此可见，我们不能有全局的mtab，肿么办呢？/proc/mounts 出来了，有人可能觉得它也是全局的啊！可你仔细看一下的话会发现，它其实是到 /proc/self/mounts 的一个符号链接！如此以来，container 里面的 /proc/mounts 和外面的当然就不会一样了！聪明啊！

所以，/etc/mtab 已经过时了，应该被抛弃，或者直接符号链接到/proc/mounts。同理，查看系统上挂载的文件系统的话，直接调用无参数的mount也是不妥的，因为那样也是读 /etc/mtab。我们应该使用 util-linux-ng 提供的一个新命令： findmnt，它是读的 /proc/self/mountinfo。

Linux Namespaces机制提供一种资源隔离方案。PID,IPC,Network等系统资源不再是全局性的，而是属于特定的Namespace。每个Namespace里面的资源对其他Namespace都是透明的。要创建新的Namespace，只需要在调用clone时指定相应的flag。Linux Namespaces机制为实现基于容器的虚拟化技术提供了很好的基础，LXC（Linux containers）就是利用这一特性实现了资源的隔离。不同container内的进程属于不同的Namespace，彼此透明，互不干扰。下面我们就从clone系统调用的flag出发，来介绍各个Namespace。

http://www.cnblogs.com/lisperl/archive/2012/05/03/2480316.html