- 09 Mar, 2019 40 commits
-
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
Copy-up the ancestors of the target. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
The internal file read/write for copy-up in kernelspace. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
Copy the inode attributes between branches. See also the document in this commit. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
Aufs uses the workqueue both synchronously and asynchronously. For sync-use-case, aufs uses its own specific wkq since doesn't want to be disturbed by other tasks on the system. For async-use-case, aufs uses the system global workqueue. Aufs has to prevent itself to being unmounted during the async-task is queued. See also the document in this commit. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
Print various info about aufs branch and superblock. This feature is enabled when CONFIG_AUFS_DEBUG and the module parameter 'debug' are set. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
For details, see previous commit. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
The generation of iinfo and dinfo inherit sbinfo's. Also iinfo generation tracks the branch inode's generation to test the matching after the branch management. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
The generation of aufs objects will be updated by the branch management (add/del branches, by later commit), and aufs will refresh the objects based upon the generation. In refreshing dinfos, aufs will find all ancestors of the given dentry and store the pointers in dynamically allocated memory. I don't think it beautiful, but I don't have any other idea. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
The structure is very similar to inode and dentry infos (in previous commits), but the internal array is for 'struct au_branch' instead of 'superblock.' Additionally the lifetime of 'struct au_sbinfo' is managed by kobject since it will be connected to sysfs by later commit. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
The structure is very similar to aufs inode info (in previous commit). Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
Print various info about aufs inode. This feature is enabled when CONFIG_AUFS_DEBUG and the module parameter 'debug' are set. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
This parameter is available only when CONFIG_AUFS_DEBUG is enabled, and its default value is 0. Setting 1 will enable the various verifications and debug outputs. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
This is a very old debugging routine for rw_semaphore I was using privately and less meaningful to other people. It was (probably) before LOCKDEP feature was introduced, but now it is based upon LOCKDEP. This is compiled when CONFIG_AUFS_DEBUG is enabled. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
See the documents in this commit. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
Very basic, simple and stupid wrappers for kmalloc family. It tries kfree_ruc() as possible, with hoping a better performance. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-