- 09 Mar, 2019 17 commits
-
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
An enhancement for udba=none if possible. The condition is same to the 'no ->d_revalidate()' patch series. In this mode, i_op->getattr() is less important, and the default VFS handler is enough. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
Now aufs becomes mountable with very few features. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
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>
-
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 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 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
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
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
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>
-