GitLab

The functions for
- create the copy-up target file
- copy filedata
- copy metadata

In copying filedata, I had tried splice_direct() instead of repeating
read/write. Surprisingly, I could not see a big difference. So let's
keep this approach for a while. Someday SEEK_DATA/SEEK_HOLE become more
popular, it may help optimizing this read/write.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

The internal file read/write for copy-up in kernelspace.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Copy the inode attributes between branches.
See also the document in this commit.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

To create/delete/rename files including copy-up, aufs acquires several
locks on the branch fs internally. These lock/unlock operations are
consolidated into struct au_pin in this commit.
au_pin handles
- LOCKDEP class
- re-validate/verify
- suspend/resume HNOTIFY

See also lookup.txt in later commit.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Actually prepare the whiteout bases on the adding writable branch.
For details, refer to previous commit.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

The writable branch prepares a few files and dirs for whiteouts.
For branch filesystems which doesn't support link(2), there is "nolwh"
attribute. On the branch which is specified this attribute, aufs never
try link(2) for whitout and always creat(2) it.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Aufs pseudo-link (plink) represents a virtual hardlink across the
branches. To implement the plink maintenance mode, aufs uses procfs.
See also the document in this commit.

There is an external user-space utility called 'auplink' in
aufs-util.git, which has these features.
- 'list' shows the pseudo-linked inode numbers and filenames.
- 'cpup' copies-up all pseudo-link to the writable branch.
- 'flush' calls 'cpup', and then 'mount -o remount,clean_plink=inum'
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

XINO and XIB files are read and written frequently after unlinked, and
it means that the remote filesystems are not suitable for them.
Additionally aufs shows their metadata via debugfs (in later commit).
To make it easier to do this, aufs expects branch filesystems to
maintain their i_size and i_blocks. And it means some filesystem are not
suitable for XINO.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

XINO and XIB files are to maintain the inode numbers in aufs
(cf. struct.txt and aufs manual in aufs-util.git).

XINO file contains just a sequence of the inode numbers, and their
offset in the file is real_inum x sizeof(inum).  So the size is limited
by s_maxbytes of the filesystem where XINO file is located.  In order to
support the larger inum, aufs stores XINO files as an internal array.

Sometimes the size of XINO file can be a problem, ie. too big,
particularly when XINO files are located on tmpfs. In this case, another
separate patch tmpfs-ino.patch in aufs4-standalone.git is recommended
(as well as vfs-ino.patch). The patch makes tmpfs to maintain inode
number within itself and suppress its discontiguous distribution.

See also the document in next commit.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

For details, see previous commit.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>