- 11 May, 2021 2 commits
-
-
J. R. Okajima authored
The commit in mainline 5dc33592e9553 2021-04-05 lockdep: Allow tuning tracing capacity constants. maks lockdep-debug.patch in aufs5-standalone.git unnecessary. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
proc_mounts.patch in aufs5-standalone.git is gone since aufs5.8. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
- 22 Jan, 2020 1 commit
-
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com> (cherry picked from commit 56b4b776c84f364384971c4cdfd66b4a2f0696d4)
-
- 31 Dec, 2019 1 commit
-
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com> (cherry picked from commit 7555811a8741218089016a6abed15a440baca476)
-
- 02 Dec, 2019 1 commit
-
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com> (cherry picked from commit 2c79658cfdc070c6fc4ea5ac3ef898f2b15fb2f3)
-
- 27 May, 2019 1 commit
-
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com> (cherry picked from commit 94c692425480664a02aaac3d6f7d496ea1d05c1f)
-
- 09 Mar, 2019 25 commits
-
-
J. R. Okajima authored
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
Generally aufs hides the name of whiteouts. But in some cases, to show them is very useful for users. For instance, creating a new middle layer (branch) by merging existing layers. See also the document in this commit. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
This feature is definitely one of the things I really don't like. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
Sometimes the aufs policy to respect the branch fs's permission bits makes users confused. IE. the direcotry permission bits on the top branch allows users to read, but the lower branch prohibts. This option may be useful for such case. See also the document in this commit. 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 an internal list of opened files to allow deleting a branch which has an opened dir. Obviously I don't like such list. There was such list in linux as sb->s_files, but in linux-3.12 s_files became containing just a part of the opened files, and in linux-3.13 it was totally gone. Aufs still needs the file list, particularly for re-setting the branch attribute from RW to RO. After resetting to RO, aufs should return EROFS for write. In order to support such case, aufs keeps the late s_files and mark_files_ro() approach. See also the document in this commit. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
Refer to this document obviously. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
For details, read the document in this commit. I don't like this approach, but there is no other way currently. But it seems that UnionMount is trying add siblings of f_dentry and d_inode for linux-4.0 or later. It may become another light for aufs too. The finfo object which has ever mmapped is excluded from refreshing (based upon fi_mmapped). Otherwise we may corrupt the process memory space. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
Support for XATTR and ACL including several branch attributes to ignore the copy error around XATTR and ACL. NFS always sets MS_POSIXACL regardless its mount option 'noacl.' When MS_POSIXACL is set, generic_permission() calls check_acl() (via acl_permission_check()) and gets -EOPNOTSUPP because the NFS branch is mounted as 'noacl.' In aufs, h_permission() should not call generic_permission() in this case. The similar thing happens in coping-up XATTR. vfs_getxattr_alloc() returns -EOPNOTSUPP. See also the document in this commit. 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
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>
-
J. R. Okajima authored
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>
-
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 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
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
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
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
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
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 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
A header file for both of kernelspace and userspace. For the new file fs/aufs/Kconfig, the maximum number of branches is customizable, and it determines the type (size) of 'aufs_bindex_t.' The type is always 'signed.' If we made it 'unsigned,' then more branches would be available. But generally I think 127 (default) is enough and it won't be a big issue. For those who wants more than 127 branches, other values are available. But we should care the size of the internal pointer arrays, and it is good for the performance to keep it in a page at most. AUFS_BRANCH_MAX_511 is mainly for 64bit systems which limits the internal array size less than 4k (511 x 8bytes < 4k). Similarly for 32bit systems, AUFS_BRANCH_MAX_1023 (1023 x 4 bytes < 4k). See also the documents in this commit. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-