- 09 Mar, 2019 8 commits
-
-
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
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
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 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>
-