GitLab

Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

With a little hope to make it easier to read.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

In mainline, by the commit
	e220140ff624 2019-02-06 fsnotify: remove dirent events from
		FS_EVENTS_POSS_ON_CHILD mask
the macro is redefined, and aufs simply follows it.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

In mainline, by the commit
	71368af9027f 2019-01-29 x86/speculation: Add PR_SPEC_DISABLE_NOEXEC
a new flag is introduced.  And aufs simply follows it.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Although I am not sure module_exit is necessary for the statically
linked module, here is it.  I hope it does no harm.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

They are historical options and a branch attribute.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Fuse doesn't want the callers to access the inode attributes without
issuing stat, and it is not assured that they are valid after lookup or
iget().
The inode attribute is critical for aufs, and aufs decided to call stat
every time for fuse.
Of course, it makes aufs slow. But when the branch fs is not fuse, stat
is not called.

Currently, only FUSE implements ->poll(), and aufs supports it.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Basically ramfs is limited for its size, and is not suitable for aufs RW
branch. But people sometimes use it as RW branch without knowing it or
with knowing it.
This configuration is for those who knows what he is doing.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Special support for filesystems which acquires an inode mutex at final
closing a file, eg, hfsplus.
This trick is very simple and stupid, just to open the file before really
necessary open to tell hfsplus that this is not the final closing.
The caller should call au_h_open_pre() after acquiring the inode mutex,
and au_h_open_post() after releasing it.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Still I am not sure how this feature breaches the security. Some people
say it doesn't matter. But I don't know.
Anyway upon the request from the users, aufs implements it as a module
option.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

It is ok that the branch is loopback-mounted.
But it had a problem if the backend fs-image is placed on another
branch, and aufs had prohibited such nested branch for a long time due
to the recursive lookup by 'loopN' daemon.
I don't remember when it was, but the daemon stopped such recursive
behaviour, but aufs is still prohibitting the nested branch via
loopback-mount.
Upon the request from users, aufs will allow the loopback-mounted branch
on another branch by another patch (aufs4-loopback.patch in
aufs4-standalone.git).
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

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>

When these attributes are specified and aufs tries opening a file on that
branch, aufs copies/moves it up.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Support for the options of MVDOWN feature, which allows to overwrite the
existing entry, and writing to the branch even if its permission is RO.
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>

For a directory which has millions of files, aufs VDIR consumes
much memory. In this case, RDU (readdir(3) in user-space) is definitely
better.
If you enable CONFIG_AUFS_RDU at compiling aufs, install libau.so from
aufs-util.git, and set some environment variables, then you can use this
feature. When readdir(3) in libau.so receives an aufs dir, it issues
ioctl(2) instead of regular readdir(3).
All merging and whiteout handling are done in userspace.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Provide info about the branches, which will be used from user-space.
This is essentially equivalent to the entries under sysfs
(/sys/fs/aufs/si_*/).
But the ioctl behaviour is atomic and never confuse the matching of the
branch id.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Provide a file descriptor corresponding the specified writable branch.
The file descriptor will be used from user-space such as FHSM and
libau.so. For details, see aufs-util.git.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Print the current data status for debugging.
The trigger key is a module parameter and you can freely change. The
default is 'a' of course.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Simple checks when the module is loaded.
This feature is compiled when CONFIG_AUFS_DEBUG is enabled.
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>

These are very old options.
Since Unionfs created 'diropq' unconditionally in mkdir(2), old users
may expect the same behaviour. But there are cases where 'diropq' is
unnecessary. The aufs default behaviour is to create 'diropq' only when
it is necessary.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Generally aufs hides the name of whiteouts. But in some cases, to show
them is very useful for users. For instance, creating a new middle layer
(branch) by merging existing layers.

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

While most people (especially who use tmpfs as top writable branch)
doesn't care, I care and think it can be a security problem.
For example, when the lower readonly branch may contain
/etc/{passwd,shadow} and the permission bits of the upper empty
branch is world-writable, then a malicious user can make these files
manually with by-passing aufs.
Aufs can do nothing but produce a warning.

For details, see aufs manual in aufs-util.git.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Introduce the new mount options, dirren and nodirren, which activates
and deactivates DIRREN feature.
In remount and unmount, the inum-list per branch should be flushed to
the file.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

When aufs meets a new dir inode on a branch in lookup, it tests whether
the inode is in the list which the branch has. If the inode is found, it
means the dir has ever been logically renamed and there is some info
about the name under that dir. Then aufs tries loading the info, and
continues looking up using the before-renamed name on the lower
branches.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

When DIRREN is enabled and activated, the error case where
aufs rename(2) used to return EXDEV will be gone.
Aufs rename(2) registers the renaming dir inum to the list in the
branch, creates the detailed info file, and returns a success.

If udba=notify option is specified with dirren, the internal detection
may not work correctly since aufs may not be able to find the target
name.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

The detailed info per renamed directory is stored in a regular file per
branch, ie. when each of two lower branches contains the same named
entry, then the created info files will be two.
The file is created internally by aufs rename(2) and loaded by lookup.
Also when the actual rename on the branch fails, the newly created or
stored info file should be all reverted.

When the renamed dir is renamed-back to the previous/original name, then
the info file has to be removed.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

DIRREN gives an identifier to every branch, and it is used as a part of
the filename of the detailed info file.
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>

This feature is definitely one of the things I really don't like.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Since aufs can have multiple writable branches, these options are
useful.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

This is a feature to optimize for rmdir and rename dir.
When the number of whiteouts under the target dir is very many, it may
take a long time to remove them all. To prevent this, 'dirwh=%d' option
specifies the watermark to decide when to remove them.

For details, see aufs manual in aufs-util.git.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Sometimes the aufs policy to respect the branch fs's permission bits
makes users confused. IE. the direcotry permission bits on the top branch
allows users to read, but the lower branch prohibts. This option may be
useful for such case.
See also the document in this commit.
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>

Implement the user interface.
Since users often wonder "Why I cannot delete this branch?", 'verbose'
option was introduced.

You may think aufs should not hold several strings for the variation of
the option, and the mount helper (/sbin/mount.aufs) can convert all
variations to a single fixed string, and in kernel space aufs should
contain this only one string.
I agree, but in our real world, many users don't install
/sbin/mount.aufs. To be convenient, aufs contains these variations.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>