- 09 Mar, 2019 7 commits
-
-
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
By default, aufs doesn't copy-up the file in open(2). The file write operation is one of the trigger of the copy-up. Although I understand that O_RDWR or O_WRONLY should trigger the copy-up, it is not a good idea for the case of open(O_RDWR) + mmap(MAP_PRIVATE). In this case, all changes are not written-back to the file on disk, and the copy-up is meaningless entirely. In other words, aufs postpone the copy-up as possible. This design also applies to the file operation after branch management. Some of the opened file need to be refreshed after add/del/mod branches. Eg. detect the revealed same named one, open it, close the old one internally while the virtual file is kept opened. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
Implement f_op->open() for non-directory. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
As a part of branch-management, aufs maintains all cached inodes, dentries, and opened files in remounting. This commits handles the opened files by counting the number of them, generating an array of their pointers. I don't like such array approach, but I don't have another idea. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
Expand finfo to support for a directory. For readdir(3), see VDIR and RDU in later 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>
-