在这里插入图片描述
大家好，我是费益洲。UnionFS 作为 Docker 的技术核心之一，实现了 Docker 镜像的分层轻量化构建、容器资源的隔离复用等目的。本文将从核心原理、主流技术实现简单介绍 UnionFS。

核心原理

Linux 的联合文件系统（Union File System，简称 UnionFS）是一种将多个目录层（Layer）“透明地”叠加为单一视图的文件系统的技术。

UnionFS 叠加的过程其实是 UnionFS 将多个目录层（Layer）联合挂载到了同一个挂载点，并进行目录层内容的覆盖。用户最终看到的是一个合并后的文件系统，但实际上文件内容可能分布在不同的存储位置。当用户在最终合并完成后的文件系统写入内容时，系统是真正将内容写入了新的文件，但是这个过程并不会改变原来的文件，这是因为 UnionFS 还用到了另外一个重要的资源管理技术，写时复制。

分层存储

层（Layer）：层是 UnionFS 的基本组成单元，每一层都包含文件系统的一部分内容，多个层联合叠加后，共同组成一个完整的文件系统。层一般分为只读层和读写层：

只读层（Read-Only Layer）：

  • 可能有多个只读层，每个只读层的内容都是固定不变的
  • 每个只读层都包含一部分系统需要的库或者二进制文件等基础文件
  • 相同的只读层只会在物理存储中存在一个，但是可以被多个容器共享
  • 多个只读层之间有上下层关系，上层可以覆盖下层的同名文件夹和文件

读写层（Read-Write Layer）：

  • 在容器技术中，读写层都是记录容器在运行过程中的内容修改
  • 每个容器在运行时都会有独立的读写层，这种设计解决了容器运行时的文件内容隔离
  • 在容器被删除时，该容器的读写层也会被删除

写时复制

写时复制机制（Copy-on-Write），即只有在需要写入（修改）时，才会进行复制操作，然后操作复制出来的副本。这种机制可以节省大量的存储空间和时间，而且不会修改原始文件。整体的工作流程如下所示：

  1. 读操作流程：系统从上层到下层依次查找文件，找到文件后直接读取，无额外开销

  2. 首次写入（修改）流程：

    在这里插入图片描述

  3. 后续写入（修改）流程：无需再次复制，直接修改读写层中已经存在的副本

主流实现技术

UnionFS 的主流实现技术有： ​​AUFS​、​​OverlayFS、​​Device Mapper​​、Btrfs/ZFS 等。AUFS 是一个用户空间的联合文件系统实现，设计目标是提供最大的灵活性和功能完整性，AUFS 是早期 Docker 的默认存储驱动。Device Mapper 不是传统意义上的文件系统，而是 Linux 内核的一个框架，用于将物理块设备映射为虚拟块设备。Btrfs 和 ZFS 都是现代文件系统，原生支持快照和子卷功能。

Docker 目前默认使用 OverlayFS 作为默认的存储系统，Docker 从早期的 AUFS 转向 OverlayFS，是综合了内核兼容性、性能、资源利用率及社区生态等多方面因素的结果：

💻 1.内核兼容性

  • AUFS 未被内核主线接纳
    AUFS 作为第三方文件系统，​​ 从未被集成到 Linux 内核主线 ​​，需用户手动为内核打补丁并重新编译，导致兼容性差。尤其在 RedHat/CentOS 等强调稳定性的发行版中无法直接使用

  • 内核原生支持 OverlayFS
    自 Linux 内核版本 3.18 起，OverlayFS 直接集成到内核主线 ​​，无需额外补丁，到 4.0 版本以后，就支持了所有功能。

⚡ 2.性能

  • OverlayFS​​ 的 CoW 操作是块级（Block-level）​​，复制单位是文件的数据块。AUFS​​ 的 CoW 操作是文件级（File-level）​​，复制单位是整个文件，对大文件操作延迟显著

📦 3.资源利用率

  • OverlayFS（overlay2） 通过符号链接管理层间依赖，避免 inode 耗尽问题。AUFS 则依赖硬链接，易导致 inode 枯竭（尤其在频繁创建/销毁容器的场景）

  • OverlayFS 支持跨容器共享页缓存：多个容器访问同一镜像文件时，内核仅缓存一份数据，降低内存占用。AUFS 无此优化，每个容器需独立缓存相同文件

📈 4.社区生态

  • 自 Docker 版本 1.12 起，OverlayFS 成为默认存储驱动，官方持续优化其稳定性与功能

  • Linux 内核社区放弃 AUFS 维护，新特性（如 ID 映射、安全增强）仅适配 OverlayFS

OverlayFS

OverlayFS（Overlay File System）是 Linux 内核中的一种联合挂载文件系统，通过将多个目录（层）透明叠加为单一视图，实现高效的分层存储管理。OverlayFS 使用四个目录来实现分层联合：

  • lower（只读层）

    • 可包含多个目录（如 Docker 镜像层）
    • 文件不可修改，多个容器可共享同一组 lower

  • upper（读写层）

    • 存储用户修改后的内容（如容器运行时的文件内容变更）
    • 文件修改或删除时，通过写时复制（CoW）将数据从 lower 复制到 upper 再操作

  • workdir（工作目录）

    • ​​ 内部临时目录，用于原子化操作（如文件复制），挂载后内容自动清空且用户不可见

  • merged（合并目录）

    • 用户访问的最终目录，动态合并 lower 和 upper 内容

整体架构如下图所示：

在这里插入图片描述

文件操作

🌳 挂载文件

1️⃣ 创建文件夹

mkdir -p /tmp/overlay-demo/{lower1,lower2,upper,work,merged}# 目录结构图如下
[root@master01 ~]# tree /tmp/overlay-demo/
/tmp/overlay-demo/
├── lower1
├── lower2
├── merged
├── upper
└── work5 directories, 0 files

2️⃣ 创建一些初始文件

echo "Config template: lower1" > /tmp/overlay-demo/lower1/config.conf
echo "Config template: lower2" > /tmp/overlay-demo/lower2/config.conf
echo "Env file content: lower1" > /tmp/overlay-demo/lower1/env
echo "Base file content: lower1" > /tmp/overlay-demo/lower1/base1.txt
echo "Base file content: lower2" > /tmp/overlay-demo/lower2/base2.txt
echo "Personal content" > /tmp/overlay-demo/upper/tom.txt
echo "Env file content: upper" > /tmp/overlay-demo/upper/env

创建初始文件后目录结构如下

[root@master01 ~]# tree /tmp/overlay-demo/
/tmp/overlay-demo/
├── lower1
│   ├── base1.txt
│   ├── config.conf
│   └── env
├── lower2
│   ├── base2.txt
│   └── config.conf
├── merged
├── upper
│   ├── env
│   └── tom.txt
└── work└── work6 directories, 7 files

3️⃣ 挂载目录

sudo mount -t overlay overlay \
-o lowerdir=/tmp/overlay-demo/lower1:/tmp/overlay-demo/lower2,\
upperdir=/tmp/overlay-demo/upper,\
workdir=/tmp/overlay-demo/work \
/tmp/overlay-demo/merged

挂载目录需要 root 权限。具体参数如下：

  • -t overlay

    表示文件系统为 overlay

  • -o lowerdir=/tmp/overlay-demo/lower1:/tmp/overlay-demo/lower2,upperdir=/tmp/overlay-demo/upper,workdir=/tmp/overlay-demo/work

    指定 lowerdir，支持多个 lower，使用:隔离，优先级从左往右依次降低；指定 upper；指定 work

  • /tmp/overlay-demo/merged

    指定 merged，即最终的挂载点、用户看到的最终的、合并后的统一视图

挂载后，目录结构如下

[root@master01 ~]# tree /tmp/overlay-demo/
/tmp/overlay-demo/
├── lower1
│   ├── base1.txt
│   ├── config.conf
│   └── env
├── lower2
│   ├── base2.txt
│   └── config.conf
├── merged
│   ├── base1.txt
│   ├── base2.txt
│   ├── config.conf
│   ├── env
│   └── tom.txt
├── upper
│   ├── env
│   └── tom.txt
└── work└── work6 directories, 12 files

查看 merged 下的 config.conf、env 内容

# config.conf
[root@master01 ~]# cat /tmp/overlay-demo/merged/config.conf
Config template: lower1
# env
[root@master01 ~]# cat /tmp/overlay-demo/merged/env
Env file content: upper

合并后的 config.conf 内容为Config template: lower1，证明了多个 lower 的优先级在挂载参数中是从左往右依次降低；合并后的 env 的内容为Env file content: upper，证明了 upper 的优先级高于 lower。整体的文件结构如下图所示

在这里插入图片描述

✨ 新增文件

echo "test" > /tmp/overlay-demo/merged/test

新增文件后，整体目录结构如下

[root@master01 ~]# tree /tmp/overlay-demo/
/tmp/overlay-demo/
├── lower1
│   ├── base1.txt
│   ├── config.conf
│   └── env
├── lower2
│   ├── base2.txt
│   └── config.conf
├── merged
│   ├── base1.txt
│   ├── base2.txt
│   ├── config.conf
│   ├── env
│   ├── test
│   └── tom.txt
├── upper
│   ├── env
│   ├── test
│   └── tom.txt
└── work└── work

从上面的目录结构可以看出，在 OverlayFS 中添加文件其实就是在 upper 中添加文件，然后合并覆盖后的结果。

文件新增的过程如下所示
在这里插入图片描述

📑 修改文件

echo "Modified base content: merged" > /tmp/overlay-demo/merged/base1.txt

修改文件后，整体目录结构如下

[root@master01 ~]# tree /tmp/overlay-demo/
/tmp/overlay-demo/
├── lower1
│   ├── base1.txt
│   ├── config.conf
│   └── env
├── lower2
│   ├── base2.txt
│   └── config.conf
├── merged
│   ├── base1.txt
│   ├── base2.txt
│   ├── config.conf
│   ├── env
│   └── tom.txt
├── upper
│   ├── base1.txt
│   ├── env
│   └── tom.txt
└── work└── work6 directories, 13 files

# lowerdir内容
[root@master01 ~]# cat /tmp/overlay-demo/lower1/base1.txt
Base file content: lower2# upperdir内容
[root@master01 ~]# cat /tmp/overlay-demo/upper/base1.txt
Modified base content: merged# merged内容
[root@master01 ~]# cat /tmp/overlay-demo/merged/base1.txt
Modified base content: merged

由上面的文件内容变化可以得出试验结果：

  • 原始文件（/tmp/overlay-demo/lower1/base1.txt）保持不变
  • 修改文件后 upper 层新增了一个 base1.txt 文件
  • 用户看到的内容其实是来自 upper 层

文件修改的过程如下所示

在这里插入图片描述

OverlayFS 中，lower 的文件是不允许修改的，在 Cow 的技术机制下，对 base1.txt 进行修改时，文件系统发现 uppder 中不存在 base1.txt，就会从 lower 中复制一份副本到 upper 中，再进行修改。修改后的内容，在合并覆盖后，用户看到的就是对 base1.txt 修改后的内容。

从 lower copy 到 upper，叫做 copy_up

🧺 删除文件

在上一步的基础上，删除/tmp/overlay-demo/merged/base1.txt

rm -f /tmp/overlay-demo/merged/base1.txt

删除后的文件目录结构如下

[root@master01 ~]# tree /tmp/overlay-demo/
/tmp/overlay-demo/
├── lower1
│   ├── base1.txt
│   ├── config.conf
│   └── env
├── lower2
│   ├── base2.txt
│   └── config.conf
├── merged
│   ├── base2.txt
│   ├── config.conf
│   ├── env
│   └── tom.txt
├── upper
│   ├── base1.txt
│   ├── env
│   └── tom.txt
└── work└── work└── #7eb6 directories, 13 files

查看 upperdir 中的文件变化

[root@master01 ~]# ls -al /tmp/overlay-demo/upper/
total 8
drwxr-xr-x 2 root root  100 Aug 22 14:30 .
drwxr-xr-x 7 root root  140 Aug 22 10:28 ..
c--------- 2 root root 0, 0 Aug 22 14:30 base1.txt
-rw-r--r-- 1 root root   24 Aug 22 11:36 env
-rw-r--r-- 1 root root   17 Aug 22 11:36 tom.txt

可以发现，lower 中的文件并不会被删除，而是会在 upper 中创建一个标记，表示这个文件已经被删除了。再次删除文件c--------- 2 root root 0, 0 Aug 22 14:30 base1.txt，发现 merged 中又可以看到 base1.txt 文件了

[root@master01 ~]# rm -f /tmp/overlay-demo/upper/base1.txt
[root@master01 ~]# tree /tmp/overlay-demo/
/tmp/overlay-demo/
├── lower1
│   ├── base1.txt
│   ├── config.conf
│   └── env
├── lower2
│   ├── base2.txt
│   └── config.conf
├── merged
│   ├── base1.txt
│   ├── base2.txt
│   ├── config.conf
│   ├── env
│   └── tom.txt
├── upper
│   ├── env
│   └── tom.txt
└── work└── work└── #7eb6 directories, 13 files

由上面的文件内容变化可以得出试验结果：

  • 原始文件（/tmp/overlay-demo/lower1/base1.txt）保持不变
  • 删除文件后 upper 层会添加一个与文件同名的删除标记
  • 删除标记后，merged 又能够看到该文件了

OverlayFS 中，删除从 lower 层映射来的文件或文件夹时，会在 upper 层添加一个与文件或文件夹同名的 c 标识文件，这个文件叫 whiteout 文件。这个标识文件意味着该文件或文件夹已经被删除，而且合并覆盖过程中，当扫描到这个文件或文件夹后，会忽略此文件或文件夹。导致 merged 层中不会看到该文件或文件夹，从用户侧来说，即达到了删除的效果。

文件删除的过程如下所示

在这里插入图片描述

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若转载，请注明出处：http://www.pswp.cn/news/920588.shtml
繁体地址，请注明出处：http://hk.pswp.cn/news/920588.shtml
英文地址，请注明出处：http://en.pswp.cn/news/920588.shtml

如若内容造成侵权/违法违规/事实不符，请联系英文站点网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

MongoDB 文档模型设计：JSON 结构的灵活性与陷阱

MongoDB 文档模型设计：JSON 结构的灵活性与陷阱

MongoDB 文档模型设计：JSON 结构的灵活性与陷阱第一章：MongoDB 文档模型基础与核心特性1.1 MongoDB 文档模型的哲学基础1.2 文档模型的优势分析1.3 与关系型数据库的深度对比第二章：文档设计模式与最佳实践2.1 嵌入式模式（Embeddi…
阅读更多...
基于SQL大型数据库的智能问答系统优化

基于SQL大型数据库的智能问答系统优化

一、食用指南 基于SQL数据库的智能问答系统设计与实现介绍了在数据库中创建表格数据问答系统的基本方法，我们可以向该系统提出关于数据库数据的问题，最终获得自然语言答案。 为了针对数据库编写有效的查询，我们需要向模型提供表名、表结构和…
阅读更多...
【计算机网络】前端基础知识Cookie、localStorage、sessionStorage 以及 Token

【计算机网络】前端基础知识Cookie、localStorage、sessionStorage 以及 Token

一、先搞懂：为什么需要这些“存储工具”？ 网页是“无状态”的——比如你登录一个网站，浏览器和服务器每次通信都是独立的，服务器默认记不住你是谁。为了让服务器“记住”用户状态（比如登录状态、购物车内容&#xff09…
阅读更多...
【语法】【C+V】【mermaid】本身常用图表类型用法快查【CSDN不支持，VSCODE可用】

【语法】【C+V】【mermaid】本身常用图表类型用法快查【CSDN不支持，VSCODE可用】

文章目录 Mermaid 简介Mermaid 由三部分组成Mermaid 的使用方法复杂图表结构的技巧饼图简介饼图语法饼图示例雷达图简介雷达图语法雷达图语法细节标题轴曲线选项 雷达图示例时间线简介时间线语法时间线示例树形图简介树形图语法树形图示例数据包图简介数据包图语法1&#xff1a…
阅读更多...
不止效率工具：AI 在文化创作中如何重构 “灵感逻辑”？

不止效率工具：AI 在文化创作中如何重构 “灵感逻辑”？

一、引言1.1 AI 创作的崛起在当今时代，AI 技术在文化创作领域的迅猛发展已成为不可忽视的现象。从文字创作领域中，AI 能够快速生成小说、诗歌，一些新闻媒体也开始运用 AI 撰写新闻稿件；到视觉艺术方面，AI 绘画软件能依…
阅读更多...
软考-系统架构设计师 专家系统(ES)详细讲解

软考-系统架构设计师 专家系统(ES)详细讲解

个人博客：blogs.wurp.top 一、ES的核心概念与价值 1. 什么是专家系统（ES）？ 专家系统是一种模拟人类专家解决特定领域问题的智能计算机程序系统。它运用特定领域内大量专家水平的知识和经验，进行推理和判断&#xff…
阅读更多...
Vue3+TS+Element-Plus+el-tree创建树节点

Vue3+TS+Element-Plus+el-tree创建树节点

1、一级树应用效果&#xff1a;代码&#xff1a;MaterialCategory.vue<script setup lang"ts" name"MaterialCategory"> ...... // 创建树&#xff08;一级树&#xff09; const createTree (dataList: IMaterialCategory[]) > {// 将原始数据转…
阅读更多...
C++基础（④链表反转（链表 + 迭代 / 递归））

C++基础（④链表反转（链表 + 迭代 / 递归））

链表反转&#xff08;链表 迭代 / 递归&#xff09; 题目描述&#xff1a;给你单链表的头节点 head&#xff0c;请你反转链表&#xff0c;并返回反转后的链表头节点。 示例&#xff1a;输入链表 1→2→3→4→5 → 输出 5→4→3→2→1。 思路提示&#xff1a;迭代法&#xff1a…
阅读更多...
面向企业级产品开发的自动化脚本实战

面向企业级产品开发的自动化脚本实战

引言&#xff1a; 在产品开发团队中&#xff0c;设计师、产品经理和工程师之间的协作常常伴随着大量重复性工作&#xff1a;手动整理设计稿链接、更新产品需求文档、同步项目状态...这些工作不仅耗时&#xff0c;还容易出错。本文将带你编写一个Python脚本&#xff0c;自动化这…
阅读更多...
科技赋能生态，智慧守护农林，汇岭生态开启农林产业现代化新篇章

科技赋能生态，智慧守护农林，汇岭生态开启农林产业现代化新篇章

在我国&#xff0c;农林业作为国民经济的基础产业&#xff0c;不仅关乎国家粮食安全与生态平衡&#xff0c;更是乡村振兴战略实施的核心领域。近年来&#xff0c;国家高度重视“三农”问题&#xff0c;大力推进乡村振兴战略&#xff0c;强调要实现农业农村现代化&#xff0c;促…
阅读更多...
贪心算法面试常见问题分类解析

贪心算法面试常见问题分类解析

一、贪心算法问题 1. 跳跃游戏系列 能否到达终点： def canJump(nums):max_reach = 0for i in range(len(nums)):if i > max_reach:return Falsemax_reach = max(max_reach, i + nums[i])return True 最少步数： def jump(nums):jumps = end = max_pos = 0for i in range(l…
阅读更多...
【3D入门-指标篇上】3D 网格重建评估指标详解与通俗比喻

【3D入门-指标篇上】3D 网格重建评估指标详解与通俗比喻

一、指标对比表格指标名称核心定义计算关键步骤通俗比喻典型应用场景Chamfer距离双向平均几何距离采样点→计算最近邻距离→取平均沙滩沙粒的平均距离差评估服装轮廓、褶皱的细微差异法向量一致性表面法向量方向匹配度计算法向量点积→取绝对值→平均刺猬刺的朝向一致程度评估布…
阅读更多...
补题报告08

补题报告08

题目背景某天&#xff0c;奇异博士在纽约圣所研究维山帝之书时&#xff0c;发现了连接不同多元宇宙的传送门网络......题目描述经研究&#xff0c;奇异博士发现每个传送门都有固定的 “时间代价”—— 正数表示双向通行&#xff08;往返时间代价相同均为正值&#xff09;&#…
阅读更多...
马斯克杀入AI编程！xAI新模型Grok Code Fast 1发布，深度评测：速度、价格与API上手指南

马斯克杀入AI编程！xAI新模型Grok Code Fast 1发布，深度评测：速度、价格与API上手指南

AI 编程的赛道&#xff0c;又迎来一位重量级玩家——马斯克的 xAI。 就在最近&#xff0c;xAI 悄然发布了一款专为编码而生的新模型&#xff1a;Grok Code Fast 1。这款模型最初以代号“Sonic”在内部流传&#xff0c;如今正式亮相&#xff0c;便凭借其 256K 超长上下文、惊人的…
阅读更多...
GaussDB 数据库架构师修炼(十八) SQL引擎-计划管理-SPM

GaussDB 数据库架构师修炼(十八) SQL引擎-计划管理-SPM

1 背景由于业务数据的变化或者数据库版本的升级&#xff0c;可能导致SQL的执行计划发生变化&#xff0c;这种变化不一定是正收益&#xff0c;这时需 要一个防止计划劣化的机制。该机制需适用于版本升级时固化计划防止计划跳变等场景。2 SPM 的功能SPM(SQL Plan Manager)功能&a…
阅读更多...
数字IC前端设计——前仿篇(VCS,DVE,Verdi)

数字IC前端设计——前仿篇(VCS,DVE,Verdi)

文章目录引言一、软件介绍1. VCS2. DVE3. Verdi二、VCS的使用1. VCS的编译流程2. 常用的编译选项1&#xff09;基础编译选项2&#xff09;调试相关选项3&#xff09;性能优化选项4&#xff09;文件和路径选项3. 常用仿真选项1&#xff09;基础仿真选项2&#xff09;运行控制选项…
阅读更多...
20250826--inter

20250826--inter

一、非对称加密的应用 非对称加密应用-CSDN博客 2、怎么避免跨站脚本攻击&#xff0c;包括还有其他的一些web安全&#xff0c;怎么做的 网页安全XSS攻击和CSRF攻击_csrf共计-CSDN博客 3、前端异常监控&#xff0c;性能监控&#xff0c;埋点&#xff0c;怎么做的 &#xff1f…
阅读更多...
MongoDB Shell

MongoDB Shell

MongoDB官方提供的单独命令行工具 MongoDB Shell Download | MongoDB 下载MongoDB Shell windows系统打开&#xff0c;直接在解压后的目录里面找到bin目录 然后双击打开mongosh.exe这个文件 看到这个命令行就表示Mongo Shell已经启动成功了 test代表 当前正在使用的数据库的…
阅读更多...
Docker03-知识点整理

Docker03-知识点整理

Docker03-知识点整理 文章目录Docker03-知识点整理1-参考网址2-知识整理2-思考题1-Docker image和Docker Native image有什么区别1. Docker Image&#xff08;Docker 镜像&#xff09;定义特点构建和使用示例2. Docker Native Image&#xff08;通常指 GraalVM Native Image 结…
阅读更多...
华为 eNSP 从入门到精通：企业级网络仿真全攻略

华为 eNSP 从入门到精通：企业级网络仿真全攻略

一、eNSP 简介华为 eNSP&#xff08;Enterprise Network Simulation Platform &#xff09;是面向企业网络的虚拟化仿真平台&#xff0c;其核心架构基于分布式虚拟化引擎和真实设备镜像&#xff0c;具备以下技术亮点&#xff1a;高度仿真&#xff1a;可模拟华为 AR 路由器、x7 …
阅读更多...
最新文章

Copyright @ 2022~2023