- 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 Jan, 2020 1 commit
-
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com> (cherry picked from commit 56b4b776c84f364384971c4cdfd66b4a2f0696d4)
-
- 09 Mar, 2019 12 commits
-
-
J. R. Okajima authored
Fuse doesn't want the callers to access the inode attributes without issuing stat, and it is not assured that they are valid after lookup or iget(). The inode attribute is critical for aufs, and aufs decided to call stat every time for fuse. Of course, it makes aufs slow. But when the branch fs is not fuse, stat is not called. Currently, only FUSE implements ->poll(), and aufs supports it. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
Support for the options of MVDOWN feature, which allows to overwrite the existing entry, and writing to the branch even if its permission is RO. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
Provide a file descriptor corresponding the specified writable branch. The file descriptor will be used from user-space such as FHSM and libau.so. For details, see aufs-util.git. 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
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
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
This is very similar to file operations, including re-open after branch management. The major part of readdir(3) is split into another object called VDIR (in previous commit). Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
Implement i_op->rmdir() with supporting logical deletion by whiteout including all children. As struct.txt in previous commit described, the target dir is renamed to a whiteout-ed temporary unique name in rmdir(2), and then removed asynchronously by the system global workqueue. 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
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
Copy the inode attributes between branches. See also the document in this commit. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-