Linux aufs（Another Union File System）是一种联合文件系统，它允许将多个目录叠加成一个统一视图，广泛应用于Docker容器的镜像分层管理，不过随着OverlayFS的成熟，aufs正逐渐退出历史舞台，但了解它依然对理解容器存储原理有重要价值。
aufs是什么：联合文件系统的核心原理
从起源到现状：aufs的演进历史
aufs最初由日本开发者Junjiro Okajima在2006年启动，目标是为Linux提供更稳定、更高效的联合文件系统，它很快被Debian、Ubuntu等主流发行版以非官方内核模块的形式收录，并在Docker 0.7版本中被选为默认存储驱动，据统计，在2014至2016年间，超过70%的Docker主机运行在aufs之上，由于aufs未能进入Linux内核主线，每次内核版本更新都会带来编译和适配问题，随着OverlayFS在3.18版本合入内核，Docker社区开始转向overlay2，并在2017年正式将其设为默认驱动，aufs的维护虽然仍在继续，但已不再是主流选择，aufs主要活跃在嵌入式Linux和某些live CD项目中，例如Slax、Knoppix等发行版仍依赖aufs实现目录合并。
aufs的工作原理：写时复制与分层挂载
aufs的核心是“写时复制”策略，它通过将多个只读目录和一个可写目录以“分支”形式叠加，对外呈现一个单一的文件系统视图，当用户尝试修改只读层中的文件时，aufs会先将文件复制到可写层，然后进行修改，下层保持不变，每个分支可以指定为只读、读写或白名单权限，这种分层设计直接映射到Docker镜像的构建过程：基础镜像层作为只读分支，容器层作为可写分支，aufs使用索引节点号（inode）映射来管理多分支，每个分支对应一个独立的文件系统，挂载时，可以通过dirs参数指定各分支的顺序和权限，
sudo mount -t aufs -o dirs=/var/lib/docker/aufs/diff/abc=rw:/var/lib/docker/aufs/diff/xyz=ro none /mnt/union通过cat /proc/mounts | grep aufs可以查看当前挂载的详细参数，aufs还为每个挂载点生成一个超级块，内部包含分支状态和世代号等信息，这些信息可以通过/sys/fs/aufs/目录下的伪文件查看。
aufs和overlay2哪个好：性能与兼容性深度对比
性能表现：不同场景下的读写速度差异
在纯读操作中,aufs和overlay2的延迟几乎无差别，因为两者都直接访问底层文件，但在写操作密集的环境下，aufs的文件查找逻辑略复杂，导致性能下降约10%至15%，业内专家指出，aufs在大量小文件创建和删除时，其whiteout文件的处理方式会占用额外的inode，而overlay2通过扩展属性（xattr）实现，效率更高，在层数较深（超过50层）时，aufs的目录解析速度有时优于over
lay2，这是其分支管理机制决定的，对于典型的Web应用容器，经常读写配置文件和日志，overlay2的页缓存共享机制能减少整体内存占用，而aufs在此场景下内存消耗略高，但在数据库容器（如MySQL）中，由于数据文件通常位于容器内部的可写层，aufs和overlay2的性能差异并不显著。
兼容性：内核主线支持与社区维护
aufs作为第三方内核模块,需要为每个内核版本编译对应的ko文件，Ubuntu、Debian等通过aufs-dkms解决了部分问题，但CentOS和RHEL官方并未提供aufs支持，而overlay2从Linux 3.18起就存在于内核主线，并持续向后移植，在Ubuntu 20.04、CentOS 8等现代发行版上，overlay2可以直接使用，aufs则需要额外安装，下表总结了主要差异：
| 特性 | aufs | overlay2 |
|---|---|---|
| 内核集成 | 第三方模块 | 内核主线（3.18+） |
| 层数限制 | 无 | 500层 |
| 写性能 | 一般，略慢 | 优，页缓存高效 |
| 维护方式 | 社区维护 | 内核社区维护 |
| Docker支持 | 已弃用，需手动指定 | 默认驱动 |
| 适用场景 | 老旧内核、特殊需求 | 现代容器环境 |
行业共识：为什么Docker官方推荐overlay2
行业共识认为,overlay2在性能、稳定性和维护便利性上全面超越aufs，Docker官方自17.06版本开始默认使用overlay2，并在后续版本中移除了对aufs的自动化支持，对于新部署，选择overlay2不仅能获得更好的性能，还能避免内核升级带来的兼容问题，aufs的维护分支虽然仍在更新，但主要针对老旧内核，对于使用4.x以上内核的用户，overlay2是更合理的选择，Docker的存储驱动文档中明确指出，overlay2是当前唯一推荐的驱动，aufs和devicemapper均已处于“遗留”状态。
Docker aufs优缺点分析：为什么逐渐被替代
优点：成熟稳定，早期主流选择
aufs在Docker初期扮演了关键角色,它的分层设计清晰，写时复制实现经过多年验证，稳定性高，aufs对分支的数量没有硬性限制，理论上可以构建无限层镜像，aufs提供了精细的权限控制，每个分支可以独立设置权限，这在某些安全敏感场景中有用，许多老运维人员习惯使用aufs，认为它“久经考验”，在Docker 1.10之前，aufs是唯一支持所有镜像层操作的驱动，这使其成为当时容器生态的基石。
缺点：内核版本依赖，性能瓶颈
aufs最大的问题是内核集成,每次内核更新，aufs模块需要重新编译，且可能因API变更而无法工
作，在CentOS等非官方支持aufs的发行版上，用户不得不依赖第三方仓库，带来了安全风险，性能方面，aufs的写操作在层数较多时容易产生碎片，并且其文件删除机制（whiteout）会占用磁盘空间，有时在容器停止后仍残留文件，这些缺点在容器批量创建和销毁的场景下尤为明显，aufs的inode使用率较高，因为每个分支都需要独立的inode表，在大量容器运行时，可能导致inode耗尽。
实际场景：aufs仍适合哪些情况
尽管aufs日薄西山,但在某些特定场景仍有价值，在嵌入式Linux环境（如Yocto项目）中，可能使用较旧的内核（2.6.x或3.x），此时overlay2不可用，而aufs可以移植，一些需要构建超过500层镜像的容器编排项目，可能会选择aufs避免层数限制，对于老旧的Docker版本（1.12以下），如果无法升级，aufs仍是可用的选项，但总体而言，对于大多数现代云原生应用，overlay2是更优选择。
在Ubuntu上配置aufs的详细步骤
检查内核支持与安装aufs-tools
确认当前内核是否支持aufs,运行lsmod | grep aufs，如果无输出，说明未加载，然后安装必要工具：
sudo apt-get update
sudo apt-get install aufs-dkms aufs-tools安装完成后,加载内核模块：
sudo modprobe aufs再次运行lsmod | grep aufs，应看到aufs模块已加载，如果系统内核较新，可能无法找到aufs-dkms，此时需要添加第三方PPA，如ppa:a-j-b/aufs，但生产环境应避免使用第三方PPA，安装完成后，可以查看aufs的版本信息：cat /sys/fs/aufs/version。
创建分支目录并挂载aufs
创建两个目录演示分层：
mkdir /tmp/readonly /tmp/writable
echo "这是只读层文件" > /tmp/readonly/test.txt挂载aufs：
sudo mount -t aufs -o dirs=/tmp/writable=rw:/tmp/readonly=ro none /tmp/unionls /tmp/union应该能看到test.txt，在/tmp/union中修改文件：
echo "修改内容" > /tmp/union/test.txt检查/tmp/writable，会发现test.txt已复制到可写层，而/tmp/readonly中的原始文件保持不变，通过mount -t aufs可以查看挂载参数，其中会显示各分支的具体路径。
验证挂载效果与分层特性
删除操作会生成whiteout文件,在/tmp/union中删除test.txt：
rm /tmp/union/test.txt/tmp/writable下会出现一个隐藏的whiteout文件（如.__deleted__或.wh.test.txt），表示该文件已在合并视图中被删除，aufs使用这种机制隐藏只读层的文件，而不实际删除它们，通过cat /sys/fs/aufs/si_/br0可以查看分支的详细信息，包括分支路径和权限，对于更复杂的场景，可以使用
aufsloop工具来管理aufs镜像，但日常操作中mount命令已足够。
aufs centos 支持情况：如何在内核中启用
CentOS用户想使用aufs面临更多挑战,CentOS 7默认内核3.10.0，未包含aufs模块，可以通过安装ELRepo仓库的kernel-ml或kernel-lt来获得较新内核，但这些内核同样不支持aufs，因为aufs不在主线，唯一可行的方法是使用aufs-dkms从源码编译，但需要确保内核头文件匹配，具体步骤：
sudo yum install kernel-devel-$(uname -r)
git clone https://github.com/sfjro/aufs-standalone.git
cd aufs-standalone
make -f <kernel-version> # 需要指定版本
sudo make install但这个过程复杂且容易出错,一旦内核更新，模块需要重新编译，在CentOS上使用aufs并不推荐，对于Docker，建议使用overlay2或devicemapper，如果非用aufs不可，可以考虑使用Ubuntu或Debian等发行版，它们对aufs的支持更友好，CentOS 8已默认使用overlay2，且内核版本较新，aufs无法编译，因此完全没有必要再去尝试。
aufs在容器存储发展史上扮演了重要角色,但面对OverlayFS的成熟，其局限性日益明显，理解aufs有助于深入掌握分层存储原理，但实际部署应优先考虑overlay2，对于希望深入理解Linux存储驱动的读者，亲手配置aufs并观察其行为是一个很好的学习路径。
Linux aufs常见问题解答
Q: aufs和overlay2有什么区别？
A: 主要区别在于内核集成度、性能和维护，aufs是第三方内核模块，支持更早的内核，但未进入主线；overlay2是内核内置的联合文件系统，从3.18起稳定，性能更优，且是Docker官方推荐驱动，aufs支持无限层数，overlay2有500层限制，但实际中很少触及，aufs的写操作性能略逊于overlay2，且whiteout机制占用更多inode。
Q: 为什么我的系统不支持aufs？
A: 现代Linux发行版默认不启用aufs，因为内核主线没有包含它，你需要安装aufs-dkms并加载模块，如果系统使用非常新的内核（如5.10+），aufs可能无法兼容，建议改用overlay2，在Ubuntu 20.04及以上版本，aufs-dkms仍在维护，但可能需要添加PPA，CentOS用户则更困难，需要自行编译内核模块。
Q: 如何将Docker从aufs切换到overlay2？
A: 备份/var/lib/docker，停止Docker服务，编辑/etc/docker/daemon.json，添加"storage-driver": "overlay2"，然后启动Docker，如果之前使用aufs，需要确保新内核支持overlay2，并重新导入镜像，实际操作中，可能需要重新拉取镜像，建议在非生产环境演练，Docker官方提供了迁移指南，但核心步骤就是修改daemon.json并重启服务。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/505763.html
