- 28 May, 2019 5 commits
-
-
J. R. Okajima authored
-
J. R. Okajima authored
-
J. R. Okajima authored
-
J. R. Okajima authored
-
J. R. Okajima authored
-
- 27 May, 2019 5 commits
-
-
J. R. Okajima authored
-
J. R. Okajima authored
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com> (cherry picked from commit 9dbd45984201453ecebcc03a91699878aa38239d)
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com> (cherry picked from commit 94c692425480664a02aaac3d6f7d496ea1d05c1f)
-
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)
-
- 23 May, 2019 2 commits
-
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
- 19 May, 2019 2 commits
-
-
J. R. Okajima authored
-
J. R. Okajima authored
This reverts commit 181d4988.
-
- 18 May, 2019 2 commits
-
-
J. R. Okajima authored
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
- 09 Apr, 2019 4 commits
-
-
J. R. Okajima authored
-
J. R. Okajima authored
With a little hope to make it easier to read. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
In mainline, by the commit e220140ff624 2019-02-06 fsnotify: remove dirent events from FS_EVENTS_POSS_ON_CHILD mask the macro is redefined, and aufs simply follows it. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
In mainline, by the commit 71368af9027f 2019-01-29 x86/speculation: Add PR_SPEC_DISABLE_NOEXEC a new flag is introduced. And aufs simply follows it. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
- 09 Mar, 2019 20 commits
-
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
Although I am not sure module_exit is necessary for the statically linked module, here is it. I hope it does no harm. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
They are historical options and a branch attribute. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
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
Basically ramfs is limited for its size, and is not suitable for aufs RW branch. But people sometimes use it as RW branch without knowing it or with knowing it. This configuration is for those who knows what he is doing. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
Special support for filesystems which acquires an inode mutex at final closing a file, eg, hfsplus. This trick is very simple and stupid, just to open the file before really necessary open to tell hfsplus that this is not the final closing. The caller should call au_h_open_pre() after acquiring the inode mutex, and au_h_open_post() after releasing it. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
Still I am not sure how this feature breaches the security. Some people say it doesn't matter. But I don't know. Anyway upon the request from the users, aufs implements it as a module option. 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
When these attributes are specified and aufs tries opening a file on that branch, aufs copies/moves it up. 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
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
For a directory which has millions of files, aufs VDIR consumes much memory. In this case, RDU (readdir(3) in user-space) is definitely better. If you enable CONFIG_AUFS_RDU at compiling aufs, install libau.so from aufs-util.git, and set some environment variables, then you can use this feature. When readdir(3) in libau.so receives an aufs dir, it issues ioctl(2) instead of regular readdir(3). All merging and whiteout handling are done in userspace. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
Provide info about the branches, which will be used from user-space. This is essentially equivalent to the entries under sysfs (/sys/fs/aufs/si_*/). But the ioctl behaviour is atomic and never confuse the matching of the branch id. 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
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
Simple checks when the module is loaded. This feature is compiled when CONFIG_AUFS_DEBUG is enabled. 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
These are very old options. Since Unionfs created 'diropq' unconditionally in mkdir(2), old users may expect the same behaviour. But there are cases where 'diropq' is unnecessary. The aufs default behaviour is to create 'diropq' only when it is necessary. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-