GitLab

This feature automatically handles MVDOWN in other commits.
In user-space, a daemon monitors the free space of the branch and issues
MVDOWN ioctl automatically when necessary. The main role is in
user-space and several options are implemented.
For a branch to join the FHSM circle, a new attribute 'fhsm' should be
specified.

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

Another ioctl feature, move-down.
The behaviour is, as you can guess, the opposite of copy-up.
The feature called FHSM (file-based hierarchical storage management, in
later commit) uses this ioctl aggressively.

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

Because of some inode is in use, the deletion of a branch can fail.
For those who wants to test the inode is busy or not, aufs provides an
ioctl, and a utility 'aubusy' in aufs-util.git.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Aufs provides some info via debugfs such as
- the branch path
- the current number of pseudo-links
- the size and the number of consumed blocks by XINO, XIB and XIGEN.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

This commits brings a list of the inode numbers which indicates the
logically renamed dir into a branch. The list will be referred in
lookup, and its lifetime is equivalent to the branch's, ie. the list is
loaded/created in adding a branch, and stored/deleted in deleting a
branch. The simple storing happens in remounting and unmounting aufs
too.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

The permissions and attributes of a branch can be modified dynamically.
See also the document in this commit.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Delete a branch which is not busy.
Aufs judges the branch is deletable by testing the opened files, the
cached dentries and inodes. Even if a directory is in use, as long as
the same named entry exist on another branch, then the branch is
deletable.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Maintain the internal array including corresponding XINO file and sysfs
entries.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

As a part of looking-up, construct a virtual inode.
After branch-management (add/del branches), the inode has to be
refreshed to represent a revealed file.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

This is the hardest test to support UDBA (users' direct branch access).
It uses 'fsnotify' internally.  Detecting UDBA, decrements the
generation of the cached aufs objects.  In the next access to the file,
aufs detects the generation is obsoleted and tries refreshing it.
Eventually aufs cache will be updated to latest status.

The fsnotify is set on the cached dirs on the non-RR branches.
The RR (real readonly) branches will never be modified and it is
unnecessary to set fsnotify for them.

This commit is for the declarations mainly, and the body parts will be
in succeeding commits.

This feature is compiled only when CONFIG_AUFS_HNOTIFY is enabled.
See also the document in this commit.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Implement exporting via NFS.
The file handle is rather large (40 bytes at most + the file handle on a
branch).
The non-virtual filesystems can use an anonymous (disconnected) dentry
as long as the inode is identified, but aufs needs a dentry with dinfo
which is usually constructed.  So aufs has to find or generate the
normal dentry from the file handle in decoding.  Eg. in aufs, there
should never be the anonymous dentry.

In decoding the file handle, if both of the dentry and the inode which
are corresponding the file handle are still in cache, then they are
returned immediately.  Otherwise aufs has to find the cached parent dir
from the file handle.  If the parent dir is not cached either, the aufs
tries these steps.
- decode the branch fs's file handle and get the parent dir
- generate the path of the parent dir on the branch
- convert the branch path to aufs's path
- lookup the inode number under the aufs' path
The last one is the slowest case.

exportfs_decode_fh() (actually reconnect_path()) acquires mutex, and
this behaviour violates the locking order between aufs si_rwsem.  This
is not a problem since internal exportfs_decode_fh() is called for the
branch fs.
Simply use lockdep_off/on to silence the lockdep message.

See also the document in later commit.
This is compiled only when CONFIG_AUFS_EXPORT is enabled.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

As a result of branch management, the virtual inode may point a
different real inode from it used to. And aufs has to maintain its
address_space_operations, since its definition may affect the
behaviour.
I know some people (including grsec-patch) doesn't like a non-const
address_space_operations, but in order to keep the consistency of the
behaviour, the correct address_space_operations is important.

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

Several policies to select one among multiple writable branches.
See also the document in previous commit.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

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>

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>

As mentioned earlier, sometimes the size of XINO file is a problem.
Aufs has a feature to truncate it asynchronously using workqueue. But it
may not be so effective in some cases, and you may want to stop
discontiguous distribution of the inode numbers on branch fs.
See also the log in another commit.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

The branch path can be much longer and it is not suitable to print via
/proc/mounts as a part of mount options. Aufs can show it either
separately via sysfs or /proc/mounts (as a part of mount options).
This approach affects the lifetime of aufs objects and sbinfo contains
kobject (in another commit). Theoretically user can disable
CONFIG_SYSFS, but the lifetime management is always necessary. So
supporting sysfs is split into two files, sysaufs.c and sysfs.c.
sysaufs.c is always compiled, but sysfs.c is compiled only when
CONFIG_SYSFS is enabled.
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>

The branch object is managed by the sbinfo object as an element of its
internal array. The iinfo and dinfo objects contain the branch id, and
it will be used to implement the correct order in branch management
(add/del).

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