GitLab

Implement basic sb_op->show_options(), statfs() and sync_fs() simply.
- show_options() doesn't print the default values (AuOpt_Def).
- statfs() will have an option to summarize the numbers from branches
  (in later commit).
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Call the functions in previous commits to refresh all.
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 branch-management, aufs maintains all cached inodes,
dentries, and opened files in remounting.
This commits handles the opened files by counting the number of them,
generating an array of their pointers. I don't like such array
approach, but I don't have another idea.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

As a part of branch-management, aufs maintains all cached inodes,
dentries, and opened files in remounting.
This commits handles the cached dentries by calling the VFS internal
function d_walk().
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

As a part of branch-management, aufs maintains all cached inodes,
dentries, and opened files in remounting.
This commits handles the cached inodes by counting the number of cached
inodes, generating an array of their pointers. I don't like such array
approach, but I don't have another idea.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

It is hard to implement readdir(3) for aufs virtual directory.
It considers the every whiteout in a single direcotry, as well as the
(first) opaque marker (diropq).
This implementation consumes memory a lot, and I'd suggest you to try
RDU (readdir in userspace) in later commit.

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

This commit is just to prepare for the succeeding commit, and split to
suppress the size of a single commit.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Expand finfo to support for a directory.
For readdir(3), see VDIR and RDU in later commits.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

The structure is very similar to iinfo and dinfo (in previous commits).
This commit is for non-dir files. For a directory, see later commit.
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>

Now aufs becomes mountable with very few features.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

In order to prevent firing the notify event from aufs itself, hnotify
feature is suspend/resume-able. They are combined with mutex lock/unlock
for the parent dir.

See also previous commits.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

The feature is constructed by two layers. One is generic interface, and
the other is exact implementation. This is rather historical. Originally
aufs implemented this feature based upon 'inotify.' Later 'fsnotify'
made 'inotify' obsolete. During the transition period, these two layers
were introduced to support both of 'inotify' and 'fsnotify.' Currently
only 'fsnotify' is supported, but the layers are kept for the future
use.

This feature is compiled only when CONFIG_AUFS_HNOTIFY is enabled.
See also the document in previous commit.
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>

The main part is in previous commit.
This commit handles the generation of aufs objects, to make sure the
inode in the file handle is still valid.
In order not to confuse NFSD, the various operation returns ESTALE for
NFSD where it used to return EBUSY.

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>

Aufs allows users' direct branch access (UDBA), ie. by-passing aufs.
Of course it will make aufs inode/dentry-caches obsolete. In order to
detect such change by the several tests, "udba=" option is introduced.

For details, see lookup.txt in later 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>

Aufs can have multiple writable branches, and there are several
policies to select one among them.
This commit implements default "top-down-parent" for both of
creating-policy and copyup-policy.

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

Imagine a sequence such like this.
- user opens a file which exists on the lower readonly branch.
- user unlinks the file (still opened). its parent dir may be removed
  too.
- user writes something to the file.

Then aufs has to copy-up the unlinked file.
Note that the copy-up in aufs is not done in open(2) by default.
This commit handles this case by copy-up the file in write(2).
The target directory is the one which aufs created internally for this
purpose.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Copy-up the ancestors of the target.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Because the copy-up operation is big and has many parameters and
functions, consolidate them in this 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>

Basically copy-up is done by these steps using au_pin (in another
commit).
- lock the target parent mutex
- lookup a negative dentry with a whiteout-ed temporary unique name
- create it
- unlock the target parent mutex
- copy filedata
- copy metadata (inode attributes)
- lock the target parent mutex
- rename the temporary name to the target name
- unlock the target parent mutex

This commit contains step2 mainly.
I hope someday aufs uses O_TMPFILE for this.
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>

Some filesystems are natively readonly. And aufs can make a few
optimization for them. This new attribute tells aufs.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

The functions to create/delete the opaque directory marker (called
'diropq') on the added writable branch.
For details, refer to previous 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>

While the whiteout on the writable branch have its effect
unconditionally (in latter commit), the one on the readonly branch can
have its effect only when this attribute is specified explicitly.
For the branch attributes, refer to the manual in aufs-util.git.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

In freeing aufs iinfo objects, it acquires the internal rw_sem (see
another commit in detail). Since iinfo can be freed anytime, a deadlock
may happen due to the rw_sem. To prevent this problem, this commit
introduces a flag per task.
This is another (very) ugly approach which I don't like.
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>

When user accesses aufs via other than fs related systemcalls, aufs
needs to identify which superblock is the target.  Here is the trick.
It is just a list of aufs superblocks.  Such way will be procfs and
MagicSysRq key.  For MagicSysRq support, see the later commit.
This is a dirty approach which I don't like, but I just don't have
another idea.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

The marker to represent that the directory is opaque (stop digging
down the branch stack) is implemented as a special whiteout.

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

The whiteout represents a logical deletion.
Although the document in this commit mentioned about rmdir(2) and
rename(2) for dir, this commit doesn't contain such functions. They will
be added in later commits.
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>