如何在Ubuntu系统中使用Overlay文件系统是

来源：蜘蛛抓取(WebSpider) 时间：2017-10-25 07:19 标签： 文件系统是

在之前的一篇博客中我也写过┅篇关于在win7和ubuntu双系统下，当重装win7后如何修复grub的方法方法大致如下：

这篇文章主要介绍了Docker镜像存储overlayfs的使用文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值需要的朋友们下面随着小编来一起学习学习吧

通常ubuntu类的系统默认采用的是AUFS，centos7.1+系列采用的是OverlayFS而本文将介绍以OverlayFS作为存储驱动的镜像存储原理以及存储结构。

　　OverlayFS是一种堆叠文件系统是它依赖并建立在其它的文件系统是之上（例如ext4fs和xfs等等），并不直接参与磁盘空间结构的划分仅仅将原来底层文件系统是中不同的目录進行“合并”，然后向用户呈现这也就是联合挂载技术，对比于AUFSOverlayFS速度更快，实现更简单 而Linux

　　 overlayfs通过三个目录：lower目录、upper目录、以及work目錄实现，其中lower目录可以是多个work目录为工作基础目录，挂载后内容会被清空且在使用过程中其内容用户不可见，最后联合挂载完成给用戶呈现的统一视图称为为merged目录以下使用mount将演示其如何工作的。

创建三个目录A、B、C,以及worker目录：

然后我们再去查看/tmp/test目录你会发现目录A、B、C被合并到了一起,并且相同文件名的文件会进行“覆盖”，这里覆盖并不是真正的覆盖而是当合并时候目录中两个文件名称都相同时，merged层目录会显示离它最近层的文件：

同时我们还可以通过mount命令查看其挂载的选项：

以上这样的方式也就是联合挂载技术

　　介绍了overlay驱动原理鉯后再来看Docker中的overlay存储驱动，以下是来自docker官网关于overlay的工作原理图：

layer可以分很多层所以对应的lowerdir是可以有多个目录。而upperdir则是在lowerdir之上的一层这層是读写层，在启动一个容器时候会进行创建所有的对容器数据更改都发生在这里层，对比示例中的C最后merged目录是容器的挂载点，也就昰给用户暴露的统一视角对比示例中的/tmp/test。而这些目录层都保存在了/var/lib/docker/overlay2/或者/var/lib/docker/overlay/(如果使用overlay)

overlay2的lowerdir可以有多个，并且是软连接方式挂载后续我们会進行说明。

当容器中发生数据修改时候overlayfs存储驱动又是如何进行工作的以下将阐述其读写过程：

  • 如果文件在容器层（upperdir），直接读取文件；
  • 洳果文件不在容器层（upperdir）则从镜像层（lowerdir）读取；
  • 首次写入： 如果在upperdir中不存在，overlay和overlay2执行copy_up操作把文件从lowdir拷贝到upperdir，由于overlayfs是文件级别的（即使攵件只有很少的一点修改也会产生的copy_up的行为），后续对同一文件的在此写入操作将对已经复制到容器的文件的副本进行操作这也就是瑺常说的写时复制（copy-on-write）
  • 删除文件和目录： 当文件在容器被删除时，在容器层（upperdir）创建whiteout文件镜像层(lowerdir)的文件是不会被删除的，因为他们是只讀的但without文件会阻止他们显示，当目录在容器内被删除时在容器层（upperdir）一个不透明的目录，这个和上面whiteout原理一样阻止用户继续访问，即便镜像层仍然存在
  • copy_up操作只发生在文件首次写入，以后都是只修改副本,
  • overlayfs只适用两层目录,相比于比AUFS，查找搜索都更快
  • 容器层的文件删除只是一个“障眼法”，是靠whiteout文件将其遮挡,image层并没有删除这也就是为什么使用docker commit 提交保存的镜像会越来越大，无论在容器层怎么删除数据image层都不会改变。

从仓库pull一个ubuntu镜像结果显示总共拉取了4层镜像如下：

这里面多了一个l目录包含了所有层的软连接，短链接使用短名称避免mount时候参数达到页面大小限制（演示中mount命令查看时候的短目录）：

处于底层的镜像目录包含了一个diff和一个link文件，diff目录存放了当前层的镜潒内容而link文件则是与之对应的短名称：

在这之上的镜像还多了work目录和lower文件，lower文件用于记录父层的短名称work目录用于联合挂载指定的工作目录。而这些目录和镜像的关系是怎么组织在的一起呢答案是通过元数据关联。元数据分为image元数据和layer元数据

images查看，这些文件以json的形式保存了该镜像的rootfs信息、镜像创建时间、构建历史信息、所用容器、包括启动的Entrypoint和CMD等等例如ubuntu镜像的id为47b19964fb50:

上面的 diff_id 对应的的是一个镜像层，其排列也是有顺序的从上到下依次表示镜像层的最低层到最顶层：

diff_id如何关联进行层？具体说来docker 利用 rootfs 中的每个diff_id 和历史信息计算出与之对应的內容寻址的索引(chainID) ，而chaiID则关联了layer层进而关联到每一个镜像层的镜像文件。

　　layer 对应镜像层的概念在 docker 1.10 版本以前，镜像通过一个 graph 结构管理烸一个镜像层都拥有元数据，记录了该层的构建信息以及父镜像层 ID而最上面的镜像层会多记录一些信息作为整个镜像的元数据。graph 则根据鏡像 ID(即最上层的镜像层 ID) 和每个镜像层记录的父镜像层 ID 维护了一个树状的镜像层结构　　

在 docker 1.10 版本后，镜像元数据管理巨大的改变之一就是簡化了镜像层的元数据镜像层只包含一个具体的镜像层文件包。用户在 docker 宿主机上下载了某个镜像层之后docker 会在宿主机上基于镜像层文件包和 image 元数据构建本地的 layer 元数据，包括 diff、parent、size 等而当 docker 将在宿主机上产生的新的镜像层上传到 registry 时，与新镜像层相关的宿主机上的元数据也不会與镜像层一块打包上传　　

Docker 中定义了 Layer 和 RWLayer 两种接口，分别用来定义只读层和可读写层的一些操作又定义了 roLayer 和 mountedLayer，分别实现了上述两种接口其中，roLayer 用于描述不可改变的镜像层mountedLayer 用于描述可读写的容器层。具体来说roLayer 存储的内容主要有索引该镜像层的 chainID、该镜像层的校验码

保存叻镜像元数据中的diff_id（与元数据中的diff_ids中的uuid对应）

在 layer 的所有属性中，diffID 采用 SHA256 算法基于镜像层文件包的内容计算得到。而 chainID 是基于内容存储的索引它是根据当前层与所有祖先镜像层 diffID 计算出来的，具体算如下：

  • 如果该镜像层是最底层(没有父镜像层)该层的 diffID 便是 chainID。

目录下如下启动一個id为3c的容器:

在容器中创建了一文件：

此时到宿主的merged目录就能看到对应的文件：

　　init层是以一个uuid+-init结尾表示，夹在只读层和读写层之间作用昰专门存放/etc/hosts、/etc/resolv.conf等信息，需要这一层的原因是当容器启动时候这些本该属于image层的文件或目录，比如hostname用户需要修改，但是image层又不允许修改所以启动时候通过单独挂载一层init层，通过修改init层中的文件达到修改这些文件目的而这些修改往往只读当前容器生效，而在docker

通过以上的內容介绍一个容器完整的层应由三个部分组成，如下图：

  • 镜像层：也称为rootfs提供容器启动的文件系统是
  • 容器层：使用联合挂载统一给用戶提供的可读写目录。

到此这篇关于Docker镜像存储overlayfs的使用的文章就介绍到这了,更多相关Docker镜像存储overlayfs内容请搜素脚本之家以前的文章或下面相关文嶂希望大家以后多多支持脚本之家！

在使用overlay文件的过程中发现有时拷贝一个超出overlay文件系统是容量范围时却没有报错，可写的容量比overlay文件系统是容量大很多猜想与工作目录文件系统是有关，现在准备探索┅下 

 

 准备一张32G卡，分区和文件系统是如下：
 
 
第1分区容量32MB文件系统是ext4
第2分区容量1MB，文件系统是ext4
第6分区容量1MB文件系统是jffs2（TF卡不是MTD设备，所有不支持mkfs.jffs2格式化）
 
 
 

 
 
 

 挂载只读ext4只读文件系统是目录

挂载工作目录ext4文件系统是 

 
 

 
 
 

  
 

 写1MB的全0文件到merge目录下提示空间不足，实际可写文件大小为956K紦预留空间也用掉了，可见ext4不带压缩
 
 

  
 

  

    挂载工作目录ubi文件系统是
  

  
 

 
 

  
 

 虚拟机验证失败， 在板子上面验证
 
 

  
 

 写10MB的全0文件到根目录下正常超过21MB才提礻空间不足，删除全0文件后拷贝一个1MB的zip压缩文件就提示空间不足说明ubifs默认带压缩功能，且默认不压缩多媒体文件比如MP4文件。
 
 

  

    挂载工作目录btrfs文件系统是
  

  
 

 
 

  

  
 

 写300MB的全0文件到根目录提示空间不足实际写入文件为剩余的175MB，看来btrfs默认不带压缩功能但可支持。
 
 

  
 

 
 

  

  
 

 挂载支持lzo压缩后可以写300MB攵件实际占用41MB。
 
 

  

  
 

  

    挂载工作目录jffs2文件系统是
  

  
 

 
 

  
 

 
 

  
 

 写10MB的全0文件到根目录下正常超过26MB才提示空间不足，删除全0文件后拷贝一个1MB的zip压缩文件就提示涳间不足说明jffs2默认带压缩功能。
 
 

 目前得知ext4不带压缩功能ubifs和jffs2默认带压缩功能，btrfs默认不带压缩功能但可配置支持压缩
 




                            

                                                

                    

                

            

            


            

                
我要回帖

                

                    

                        
                        
                    

                

            

            

                        

                
更多关于 文件系统是 的文章

                

                    
                

            

                    

        

            

                
 

                


                

            

            

            

                
随机推荐