- 18 Jun, 2020 1 commit
-
-
J. R. Okajima authored
By the recent commit 21913077f9918 2020-06-17 aufs: do not call i_readcount_inc() a very old bug was fixed, which is inblance counter. But still aufs needs to call i_readcount_inc() when the branch permission is chaned from RW to RO. Otherwise the counter reaches 0 and BUG() in i_readcount_dec() will be activated. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com> (cherry picked from commit f10aea57d39d6cd311312e9e7746804f7059b5c8)
-
- 22 Jan, 2020 1 commit
-
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com> (cherry picked from commit 56b4b776c84f364384971c4cdfd66b4a2f0696d4)
-
- 03 Aug, 2019 1 commit
-
-
J. R. Okajima authored
By the commit, 387e3746d01c 2019-06-19 locks: eliminate false positive conflicts for write lease inode->i_readcount becomes common to CONFIG_IMA and CONFIG_FILE_LOCKING. In aufs branch management, eg. re-setting the branch attribute RW to RO, aufs has to maintain i_readcount too. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
- 09 Mar, 2019 22 commits
-
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
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>
-
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
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
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>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
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>
-
J. R. Okajima authored
Delete a branch which is not busy. Aufs judges the branch is deletable by testing the opened files, the cached dentries and inodes. Even if a directory is in use, as long as the same named entry exist on another branch, then the branch is deletable. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
Maintain the internal array including corresponding XINO file and sysfs entries. 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
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
The internal file read/write for copy-up in kernelspace. 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
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 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
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>
-