- 06 Mar, 2021 1 commit
-
-
J. R. Okajima authored
In mainline, by the commit 549c7297717c3 2021-01-24 fs: make helpers idmap mount aware and its series, a new parameter 'user_ns' was added to some inode operations. Aufs simply follows it, but it is still testing. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
- 22 Dec, 2020 1 commit
-
-
J. R. Okajima authored
Finally set_fs() is gone by the commit, 3c57fa13f6bf3 2020-10-04 asm-generic: make the set_fs implementation optional Now aufs removes all [gs]et_fs() calls. It heavily affects XINO file I/O and some others. 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)
-
- 27 May, 2019 1 commit
-
-
J. R. Okajima authored
At the mount-time, XINO files are created and removed very soon. When multiple mounts with being given the same XINO file path executed in parallel, some of them may fail in creating XINO due to EEXIST. Introducing a local mutex, make it serialized. By default, XINO is created at the top dir of the first writable branch. In this case, the new mutex won't be used. Obviously this is an unnecessary overhead when the XINO file path is not same, and such lock should be done by inode_lock() for the parent dir. Actually au_xino_create2() behaves in this manner. Then why didn't I apply the same way to this au_xino_create()? It is just because of my laziness. Calling VFS filp_open() here is easy for me. Reported-by: Kirill Kolyshkin <kolyshkin@gmail.com> Signed-off-by: J. R. Okajima <hooanon05g@gmail.com> (cherry picked from commit 30d9273f2a1ce331b1a79b770bdb4c493919a673)
-
- 09 Mar, 2019 21 commits
-
-
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
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
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
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
As a part of looking-up, construct a virtual inode. After branch-management (add/del branches), the inode has to be refreshed to represent a revealed file. 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
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
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
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
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
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
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>
-