Introduction and use of OverlayFS

Posted by Namadoor on Tue, 08 Mar 2022 11:34:28 +0100

Reference ----- > https://www.cnblogs.com/arnoldlu/p/13055501.html

 

Test environment: Linux al-B250-HD3 4.15.0-99-generic #100~16.04.1-Ubuntu SMP Wed Apr 22 23:56:30 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

1. Introduction to overlayfs

OverlayFS is a stacked file system. It relies on and builds on other file systems, does not directly participate in the division of disk space structure, and only "merges" different directories and files in the original file system.

Therefore, OverlayFS is more like an adhesive, outputting the "collection" of multiple file system directories.

1.1 OverlayFS application

1.1.1 Overlay Driver

1.1.2 Overlay Driver2

2. Overlay FS analysis

2.1 kernel configuration: enable overlay FS

File systems->Overlay filesystem support

 

2.2 overlay FS architecture analysis

Enable config_ OVERLAY_ After FS, the relevant codes of overlay FS are as follows:

fs/overlayfs/
├── copy_up.c
├── dir.c
├── inode.c
├── Kconfig
├── Makefile
├── overlayfs.h
├── readdir.c
└── super.c

The relevant help files are in documentation / filesystems / overlayfs txt.

3. Overlay FS mount

Mount an overlay file system through mount - t overlay - O < Options > overlay < mount point >.

< mount point > is the mount point of the final overlay.

The overlay options are as follows:

  • Lowerdir = < dir >: Specifies the directory of the lower layer that the user needs to mount. The lower layer supports multiple directories. The priority will be reduced in turn with the interval of ":". Up to 500 layers are supported.
  • Upperdir = < dir >: Specifies the upper layer directory that the user needs to mount. The upper layer takes precedence over all lower layer directories.
  • Workdir = < dir >: Specifies the working base directory used to store temporary and indirect files after the file system is mounted.
  • default_permissions:
  • redirect_dir=on/off: turn on or off the redirect directory feature. After it is turned on, it can support the rename / rename system call of merged directory and pure lower layer directory.
  • index=on/off: turn on or off the index feature, which can avoid the hardlink copyup broken problem.

Next, overlay lower and upper, mount them to the merge directory, and the temporary workdir is the work directory.

  mount -t overlay -o lowerdir=lower,upperdir=upper,workdir=work overlay merge

As follows, lower and upper are also overlaid to merge, but merge is a read-only attribute.

mount -t overlay -o lowerdir=upper:lower overlay merge

4. Use of overlayfs

After OverlayFS merging using mount above, follow the following rules:

  • When files with the same name exist in lowerdir and upperdir directories, lowerdir files will be hidden and users can only see upperdir files.
  • lowerdir low priority files with the same name in the same directory will be hidden.
  • If a directory with the same name exists, the contents of the lowerdir and upperdir directories will be merged.
  • When the user modifies the data from upperdir in mergedir, the data will be directly written to the original directory in upperdir, and the same is true for deleting files.
  • When the user modifies the data from lowerdir in mergedir, the content in lowerdir will not change. Because lowerdir is read-only, when users want to modify the data from lowerdir, overlayfs will first copy a copy of the file in lowerdir to upperdir. Subsequent modifications or deletions will be made in the copy under upperdir, and the original file in lowerdir will be hidden.
  • If a directory is simply from lowerdir or lowerdir and upperdir are combined, the rename system call cannot be made by default. However, it can be renamed through mv. If you want to support rename, you need CONFIG_OVERLAY_FS_REDIRECT_DIR.

4.1 build test cases

Build the test case through the following script.

#!/bin/sh

create() {
  mkdir -p lower/common-dir lower/lower-dir upper/common-dir upper/upper-dir merge work
  touch lower/common-dir/lower-file lower/lower-dir/lower-file upper/common-dir/upper-file upper/upper-dir/upper-file
  echo "From lower." > lower/common-file
  echo "From upper." > upper/common-file
  echo "From lower." > lower/lower-file
  echo "From upper." > upper/upper-file

  mount -t overlay -o lowerdir=lower,upperdir=upper,workdir=work overlay merge
  #mount -t overlay -o lowerdir=upper:lower overlay merge
}

delete() {
  umount merge
  rm -rf lower upper merge work
}

case $1 in
  create)
    create
    ;;
  delete)
    delete
    ;;
esac

Through sudo/ overlayfs_ test. SH create / delete creates a test environment or empties it.

The results of the OverlayFS built by the above script are as follows: the contents of the common dir directory of the two are merged; The duplicate file common file is the common file in uppderdir.

The directory structure is as follows:

├── lower
│   ├── common-dir
│   │   └── lower-file
│   ├── common-file
│   ├── lower-dir
│   │   └── lower-file
│   └── lower-file
├── merge
│   ├── common-dir
│   │   ├── lower-file
│   │   └── upper-file
│   ├── common-file
│   ├── lower-dir
│   │   └── lower-file
│   ├── lower-file
│   ├── upper-dir
│   │   └── upper-file
│   └── upper-file
├── overlayfs_test.sh
├── upper
│   ├── common-dir
│   │   └── upper-file
│   ├── common-file
│   ├── upper-dir
│   │   └── upper-file
│   └── upper-file
└── work
    └── work [error opening dir]

4.2 new files or directories

Create new dir, new file, common dir / new file and lower dir / new file under merge.

1 2 sudo mkdir merge/new-dir sudo touch merge/new-file merge/common-dir/new-file merge/lower-dir/new-file

The results are as follows:

.
├── lower
│   ├── common-dir
│   │   └── lower-file
│   ├── common-file
│   ├── lower-dir
│   │   └── lower-file
│   └── lower-file
├── merge
│   ├── common-dir
│   │   ├── lower-file
│   │   ├── new-file
│   │   └── upper-file
│   ├── common-file
│   ├── lower-dir
│   │   ├── lower-file
│   │   └── new-file
│   ├── lower-file
│   ├── new-dir
│   ├── new-file
│   ├── upper-dir
│   │   └── upper-file
│   └── upper-file
├── overlayfs_test.sh
├── upper
│   ├── common-dir
│   │   ├── new-file
│   │   └── upper-file
│   ├── common-file
│   ├── lower-dir
│   │   └── new-file
│   ├── new-dir
│   ├── new-file
│   ├── upper-dir
│   │   └── upper-file
│   └── upper-file
└── work
    └── work [error opening dir]

It can be seen that the lower directory has not changed. Add Lower Dir / new file in upper. All other new files are also in upper.

4.3 modifying files or directories

Modify common dir / lower file, common dir / upper file, lower dir / lower file, Upper Dir / upper file, rename Lower Dir to new dir.

vi Change the content to"new": 
  merge/common-dir/upper-file
  merge/common-dir/lower-file
  merge/lower-dir/lower-file
  merge/upper-dir/upper-file
  merge/common-file

sudo mv merge/lower-dir merge/new-dir

The results are as follows:

.
├── lower
│   ├── common-dir
│   │   └── lower-file
│   ├── common-file
│   ├── lower-dir
│   │   └── lower-file
│   └── lower-file
├── merge
│   ├── common-dir
│   │   ├── lower-file
│   │   └── upper-file
│   ├── common-file
│   ├── lower-file
│   ├── new-dir
│   │   └── lower-file
│   ├── upper-dir
│   │   └── upper-file
│   └── upper-file
├── overlayfs_test.sh
├── upper
│   ├── common-dir
│   │   ├── lower-file
│   │   └── upper-file
│   ├── common-file
│   ├── lower-dir
│   ├── new-dir
│   │   └── lower-file
│   ├── upper-dir
│   │   └── upper-file
│   └── upper-file
└── work
    └── work [error opening dir]

Similarly, the file in lower is not modified, and all modifications are generated in upper.

Among them, upper / common dir / upper file, common file and Upper Dir / upper file are modified, and common dir / lower file, new dir / lower file and Lower Dir are added.

Among them, new dir / lower file is renamed from Lower Dir / lower file file, and the New Lower Dir is a special file.

c--------- 1 root root 0, 0 6 August 14:17 upper/lower-dir

Overlayfs designed a set of "deception" - Whiteout file for this scenario. The Whiteout file is created when the user deletes a file. It is used to shield the underlying file with the same name. At the same time, the file is invisible in the merge, so the user can't see the deleted file or directory.

Whiteout file is not an ordinary file, but a character device with primary and secondary device numbers of 0 (which can be manually created by "mknod < name > C 0 0" command). When the user checks the directory entries of the parent directory through ls command (which will be called by readddir system) in merge, overlayfs will automatically filter out the whiteout file itself and the lower layer files and directories with the same name, The purpose of hiding the file is achieved, which makes the user think that the file has been deleted.

4.4 deleting files or directories

Delete all directories and files in the merge.

sudo rm -rf merge/*

The results are as follows:

.
├── lower
│   ├── common-dir
│   │   └── lower-file
│   ├── common-file
│   ├── lower-dir
│   │   └── lower-file
│   └── lower-file
├── merge
├── overlayfs_test.sh
├── upper
│   ├── common-dir
│   ├── common-file
│   ├── lower-dir
│   └── lower-file
└── work
    └── work [error opening dir]

It can be seen that all directories and files in upper have been deleted, and all directories and files in lower have corresponding whiteout files.

 

Reference documents:< In depth understanding of overlayfs (I): first acquaintance>,<In depth understanding of overlay fs (II): use and principle analysis>,<OverlayFS>,<Introduction to OVERLAYFS of dock storage driver>.