Documentation/filesystems/aufs/design/01intro.txt

   1
   2 # Copyright (C) 2005-2017 Junjiro R. Okajima
   3 #
   4 # This program is free software; you can redistribute it and/or modify
   5 # it under the terms of the GNU General Public License as published by
   6 # the Free Software Foundation; either version 2 of the License, or
   7 # (at your option) any later version.
   8 #
   9 # This program is distributed in the hope that it will be useful,
  10 # but WITHOUT ANY WARRANTY; without even the implied warranty of
  11 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  12 # GNU General Public License for more details.
  13 #
  14 # You should have received a copy of the GNU General Public License
  15 # along with this program.  If not, see <http://www.gnu.org/licenses/>.
  16
  17 Introduction
  18 ----------------------------------------
  19
  20 aufs [ei ju: ef es] | /ey-yoo-ef-es/ | [a u f s]
  21 1. abbrev. for "advanced multi-layered unification filesystem".
  22 2. abbrev. for "another unionfs".
  23 3. abbrev. for "auf das" in German which means "on the" in English.
  24    Ex. "Butter aufs Brot"(G) means "butter onto bread"(E).
  25    But "Filesystem aufs Filesystem" is hard to understand.
  26 4. abbrev. for "African Urban Fashion Show".
  27
  28 AUFS is a filesystem with features:
  29 - multi layered stackable unification filesystem, the member directory
  30   is called as a branch.
  31 - branch permission and attribute, 'readonly', 'real-readonly',
  32   'readwrite', 'whiteout-able', 'link-able whiteout', etc. and their
  33   combination.
  34 - internal "file copy-on-write".
  35 - logical deletion, whiteout.
  36 - dynamic branch manipulation, adding, deleting and changing permission.
  37 - allow bypassing aufs, user's direct branch access.
  38 - external inode number translation table and bitmap which maintains the
  39   persistent aufs inode number.
  40 - seekable directory, including NFS readdir.
  41 - file mapping, mmap and sharing pages.
  42 - pseudo-link, hardlink over branches.
  43 - loopback mounted filesystem as a branch.
  44 - several policies to select one among multiple writable branches.
  45 - revert a single systemcall when an error occurs in aufs.
  46 - and more...
  47
  48
  49 Multi Layered Stackable Unification Filesystem
  50 ----------------------------------------------------------------------
  51 Most people already knows what it is.
  52 It is a filesystem which unifies several directories and provides a
  53 merged single directory. When users access a file, the access will be
  54 passed/re-directed/converted (sorry, I am not sure which English word is
  55 correct) to the real file on the member filesystem. The member
  56 filesystem is called 'lower filesystem' or 'branch' and has a mode
  57 'readonly' and 'readwrite.' And the deletion for a file on the lower
  58 readonly branch is handled by creating 'whiteout' on the upper writable
  59 branch.
  60
  61 On LKML, there have been discussions about UnionMount (Jan Blunck,
  62 Bharata B Rao and Valerie Aurora) and Unionfs (Erez Zadok). They took
  63 different approaches to implement the merged-view.
  64 The former tries putting it into VFS, and the latter implements as a
  65 separate filesystem.
  66 (If I misunderstand about these implementations, please let me know and
  67 I shall correct it. Because it is a long time ago when I read their
  68 source files last time).
  69
  70 UnionMount's approach will be able to small, but may be hard to share
  71 branches between several UnionMount since the whiteout in it is
  72 implemented in the inode on branch filesystem and always
  73 shared. According to Bharata's post, readdir does not seems to be
  74 finished yet.
  75 There are several missing features known in this implementations such as
  76 - for users, the inode number may change silently. eg. copy-up.
  77 - link(2) may break by copy-up.
  78 - read(2) may get an obsoleted filedata (fstat(2) too).
  79 - fcntl(F_SETLK) may be broken by copy-up.
  80 - unnecessary copy-up may happen, for example mmap(MAP_PRIVATE) after
  81   open(O_RDWR).
  82
  83 In linux-3.18, "overlay" filesystem (formerly known as "overlayfs") was
  84 merged into mainline. This is another implementation of UnionMount as a
  85 separated filesystem. All the limitations and known problems which
  86 UnionMount are equally inherited to "overlay" filesystem.
  87
  88 Unionfs has a longer history. When I started implementing a stackable
  89 filesystem (Aug 2005), it already existed. It has virtual super_block,
  90 inode, dentry and file objects and they have an array pointing lower
  91 same kind objects. After contributing many patches for Unionfs, I
  92 re-started my project AUFS (Jun 2006).
  93
  94 In AUFS, the structure of filesystem resembles to Unionfs, but I
  95 implemented my own ideas, approaches and enhancements and it became
  96 totally different one.
  97
  98 Comparing DM snapshot and fs based implementation
  99 - the number of bytes to be copied between devices is much smaller.
 100 - the type of filesystem must be one and only.
 101 - the fs must be writable, no readonly fs, even for the lower original
 102   device. so the compression fs will not be usable. but if we use
 103   loopback mount, we may address this issue.
 104   for instance,
 105         mount /cdrom/squashfs.img /sq
 106         losetup /sq/ext2.img
 107         losetup /somewhere/cow
 108         dmsetup "snapshot /dev/loop0 /dev/loop1 ..."
 109 - it will be difficult (or needs more operations) to extract the
 110   difference between the original device and COW.
 111 - DM snapshot-merge may help a lot when users try merging. in the
 112   fs-layer union, users will use rsync(1).
 113
 114 You may want to read my old paper "Filesystems in LiveCD"
 115 (http://aufs.sourceforge.net/aufs2/report/sq/sq.pdf).
 116
 117
 118 Several characters/aspects/persona of aufs
 119 ----------------------------------------------------------------------
 120
 121 Aufs has several characters, aspects or persona.
 122 1. a filesystem, callee of VFS helper
 123 2. sub-VFS, caller of VFS helper for branches
 124 3. a virtual filesystem which maintains persistent inode number
 125 4. reader/writer of files on branches such like an application
 126
 127 1. Callee of VFS Helper
 128 As an ordinary linux filesystem, aufs is a callee of VFS. For instance,
 129 unlink(2) from an application reaches sys_unlink() kernel function and
 130 then vfs_unlink() is called. vfs_unlink() is one of VFS helper and it
 131 calls filesystem specific unlink operation. Actually aufs implements the
 132 unlink operation but it behaves like a redirector.
 133
 134 2. Caller of VFS Helper for Branches
 135 aufs_unlink() passes the unlink request to the branch filesystem as if
 136 it were called from VFS. So the called unlink operation of the branch
 137 filesystem acts as usual. As a caller of VFS helper, aufs should handle
 138 every necessary pre/post operation for the branch filesystem.
 139 - acquire the lock for the parent dir on a branch
 140 - lookup in a branch
 141 - revalidate dentry on a branch
 142 - mnt_want_write() for a branch
 143 - vfs_unlink() for a branch
 144 - mnt_drop_write() for a branch
 145 - release the lock on a branch
 146
 147 3. Persistent Inode Number
 148 One of the most important issue for a filesystem is to maintain inode
 149 numbers. This is particularly important to support exporting a
 150 filesystem via NFS. Aufs is a virtual filesystem which doesn't have a
 151 backend block device for its own. But some storage is necessary to
 152 keep and maintain the inode numbers. It may be a large space and may not
 153 suit to keep in memory. Aufs rents some space from its first writable
 154 branch filesystem (by default) and creates file(s) on it. These files
 155 are created by aufs internally and removed soon (currently) keeping
 156 opened.
 157 Note: Because these files are removed, they are totally gone after
 158       unmounting aufs. It means the inode numbers are not persistent
 159       across unmount or reboot. I have a plan to make them really
 160       persistent which will be important for aufs on NFS server.
 161
 162 4. Read/Write Files Internally (copy-on-write)
 163 Because a branch can be readonly, when you write a file on it, aufs will
 164 "copy-up" it to the upper writable branch internally. And then write the
 165 originally requested thing to the file. Generally kernel doesn't
 166 open/read/write file actively. In aufs, even a single write may cause a
 167 internal "file copy". This behaviour is very similar to cp(1) command.
 168
 169 Some people may think it is better to pass such work to user space
 170 helper, instead of doing in kernel space. Actually I am still thinking
 171 about it. But currently I have implemented it in kernel space.