- 09 Mar, 2019 6 commits
-
-
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 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
When user accesses aufs via other than fs related systemcalls, aufs needs to identify which superblock is the target. Here is the trick. It is just a list of aufs superblocks. Such way will be procfs and MagicSysRq key. For MagicSysRq support, see the later commit. This is a dirty approach which I don't like, but I just don't have another idea. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
This is a very old debugging routine for rw_semaphore I was using privately and less meaningful to other people. It was (probably) before LOCKDEP feature was introduced, but now it is based upon LOCKDEP. This is compiled when CONFIG_AUFS_DEBUG is enabled. 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>
-