第三章 overlayfs.pdf

叠合式文件系统—— overlayfs 内核组 三百 sanbai@ Overlayfs 提纲  linux 文件系统的一些基础知识  怎么发现overlayfs （源起）  Linux 上vfs 的原  overlayfs 的原 基础知识  Linux 的page cache – read/write – mmap  常见疑问：好多内存都被cache 占了，我想手工释放 它 – 答：不需要，linux 系统在需要内存时，自己会释放 cache  常见疑问：我想让cache 一直保留不被收回，怎么 做？ – 答：mmap 后mloc 基础知识  文件系统的“快照”（snapshot ） – 多个inode 指向相同的物理磁盘块 – 需要引用计数以记录一个磁盘块被几个 inode 使用了 Image from /2010/06/netapp-fractional-reserve.html Overlayfs 提纲  linux 文件系统的一些基础知识  怎么发现 overlayfs （源起）  Linux 上vfs 的原  overlayfs 的原 源起  需求：在一个linux 系统上，跑多个不同应用，这些应用由不同的运 维人员来操作，为了避免互相干扰，希望运维只能看见自己的文件， 而看不见别的应用的文件信息  常见解决方案：linux 系统上装多个虚拟机  缺陷：多个应用公用的一些动态链接库（比如 libc.so ）和配置文件 （比如 hosts.conf ）就复制了多份。例如：原先一个系统在运行时 系统文件占了500M 的cache ，那么现在装了4 台虚拟机，就一共 要占2G 的cache 。  平台的层次越深，这种浪费就越大，c/c++ 程序只是用一些系统 的.so ，java 程序依靠jvm ，需要的公用库就更多了。 源起  我们的最初方案：把linux 系统装到ext4 上，然后做4 个 snapshot （ 快照“），这4 个snapshot 分别mount 到4 个目录，4 个运维人员chroot 到这4 个目录里，然后就自己 维护自己的，干扰不到别人的文件。（我们最初以为一个文件 和它的快照是共享cache 的）  疑问：直接把系统常用的动态链接库做4 个软链接出来，给4 个运维用不就行了？  答：第一，动态链接库以及各种系统文件很多，不可能一一做 软链接；第二，也是关键的一点，如果其中一个运维人员错误 操作——例如覆盖写了某个系统文件，那么其他的运维将会受 影响，因为软链接实际指向的是同一个实际文件。 源起  ext4 snapshot 方案的纰漏：一个文件和它的snapshot 各自有自己的page cache ，并非共享！  现有linux 的支持快照的文件系统 （ext2/ext3/ext4 、btrfs 、ocfs2 ），它们的快照在 mount 以后，就是个“新的”文件系统、“新的” inode ， 新的inode 就有自己“新的” page cache  我们还考虑过link-ref （多个文件共享一样的磁盘块）， 但问题一样：不同的inode 无法共享一套page cache 源起  最终方案：overlayfs  overlayfs 能将两个目录“合并”，比如两个目录： – dir1/ 目录里有 ./fire ./water