在Linux上，如果你想查看一个文件的大小，可以使用命令ls -l，但是如果你想查看一个目录的大小(包含目录下的文件)，ls无法做到，基本上用ls命令查看到的目录大小都是4K（假设块大小为4K）:

1
2
3
4
5
6
7
8
9
10
11
12
13

chenximing@chenximing-MS-7823:~$ ls -lh
...
...
-rw-rw-r--  1 chenximing chenximing  16K  9月 27 16:38 sysstat-8.0.4.1.tar.gz
-rwxrwxr-x  1 chenximing chenximing  492  5月  2  2017 tmp_lat.sh
drwxr-xr-x  2 chenximing chenximing 4.0K  4月  5  2017 公共的
drwxr-xr-x  2 chenximing chenximing 4.0K  4月  5  2017 模板
drwxr-xr-x  2 chenximing chenximing 4.0K  4月  5  2017 视频
drwxr-xr-x  2 chenximing chenximing 4.0K 10月  9 11:39 图片
drwxr-xr-x  5 chenximing chenximing 4.0K 10月 11 10:15 文档
drwxr-xr-x  2 root       root       4.0K  4月  6  2017 下载
drwxr-xr-x  2 chenximing chenximing 4.0K  4月  5  2017 音乐
drwxr-xr-x  2 chenximing chenximing 4.0K  8月 20 17:53 桌面

这是由于linux下目录和一般文件在磁盘上都是通过元数据和数据进行记录，在创建一个目录时，分配一个元数据(inode)，并为其分配一个数据块(block)。目录的数据区，也就是目录的block中，记录的是目录下文件inode和文件名的条目列表。当目录下的文件数量较少时，一个块已经足够记录，因此ls命令查看到的目录大小实际上是目录占用的block大小。当目录下文件较多时，需要更多的block来记录，此时ls命令看到的目录大小会变成8K，12K…但是对于一般文件来说ls命令能反映出其实际大小，而不是占用的block大小

所以，在Linux上，如果想要查看目录总大小时，就需要用到du命令

内核版本4.4.68

在OverlayFS联合挂载目录下，使用命令ls看到的文件实际上来自联合挂载的upper层和lower层。前面的博文中有提到过，OverlayFS的本质在于实现操作转化，因此在对OverlayFS中的一个目录进行搜索时（使用命令ls时），实际上会搜索目录对应upper层和lower层的目录，然后对搜索结果进行处理、展示。最终得到我们在OverlayFS下ls dir看到的内容

这篇文章就是以OverlayFS根目录为例，分析ls merged时，OverlayFS根目录搜索，处理的过程

内核版本为4.4.68

这篇文章通过内核源码分析OverlayFS的注册与挂载过程

假设你对OverlayFS的层次关系已经有一个基本的了解。如果对OverlayFS的层以及联合挂载没有概念，建议先补充下相关知识，因为挂载OverlayFS时会使用到层

分析会尽可能避开公有部分(每种文件系统注册和挂载过程中都会涉及的内容)，而更多的关注OverlayFS独有部分

内核版本为4.4.68

我们知道，在OverlayFS中，读写操作和文件所在的层息息相关。尤其是写一个只读层的文件时，由于只读层不能修改，因此会触发copy-up操作。那么内核怎么知道一个文件到底是一个upper层（读写层）的文件还是一个lower（只读层）的文件？也就是说，在OverlayFS中如何记录文件的层次信息？

在Linux中，VFS为上层应用提供了访问下层文件系统的统一接口，它将文件相关的概念进行了抽象，同时提供了对这些抽象概念的操作接口

Btrfs是下一代copy-on-write文件系统，它支持很多先进存储技术，这使得它能很好的适用与Docker。Btrfs已经引入了内核主线

Docker的btrfs存储驱动利用了很多Btrfs的特征来管理容器和镜像。这些特征有块级操作，瘦供给(thin provisioning)，copy-on-write快照，以及管理轻便性。你可以很容易的将多个物理块设备结合成一个单一的Btrfs文件系统

这篇文章中使用“btrfs”代表Docker的Btrfs存储驱动，使用“Btrfs”表示Btrfs文件系统。注意在Ubuntu或者Debian上只有Docker CE支持btrfs存储驱动，在SLES上，只有Docker EE / CS 支持btrfs存储驱动

Docker 的 devicemapper 存储驱动利用了内核 device mapper 的 thin provisioning（自动精简配置）和 snapshotting（快照）的能力来管理镜像和容器

devicemapper使用Docker专用的块设备，操作为块级而不是文件级。可以通过为Docker主机添加物理存储来扩充这些设备

这篇文章是对Docker官网中 devicemapper 存储驱动使用文档的翻译

该文为译文，代码为本地实际运行的结果，部分内容有修改或删除。实验环境为Ubuntu 14.04；

docker支持的存储驱动有aufs、overlayFS、devicemapper、btrfs、zfs和vfs;

这篇文章主要谈谈aufs；

“通用唯一识别码(Universally Unique identifier，简称UUID)；
其目的，是让分布式系统中的所有元素，都能有唯一的辨识信息，而不需要通过中央控制端来做辨识…”