- 09 Mar, 2019 30 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>
-
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
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
The detailed info per renamed directory is stored in a regular file per branch, ie. when each of two lower branches contains the same named entry, then the created info files will be two. The file is created internally by aufs rename(2) and loaded by lookup. Also when the actual rename on the branch fails, the newly created or stored info file should be all reverted. When the renamed dir is renamed-back to the previous/original name, then the info file has to be removed. 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
This is a feature to optimize for rmdir and rename dir. When the number of whiteouts under the target dir is very many, it may take a long time to remove them all. To prevent this, 'dirwh=%d' option specifies the watermark to decide when to remove them. For details, see aufs manual in aufs-util.git. Signed-off-by:
J. R. Okajima <hooanon05g@gmail.com>
-
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 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
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
Some filesystems are natively readonly. And aufs can make a few optimization for them. This new attribute tells aufs. Signed-off-by:
J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
The functions to create/delete the opaque directory marker (called 'diropq') on the added writable branch. For details, refer to previous commit. Signed-off-by:
J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
Actually prepare the whiteout bases on the adding writable branch. For details, refer to previous commit. 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
While the whiteout on the writable branch have its effect unconditionally (in latter commit), the one on the readonly branch can have its effect only when this attribute is specified explicitly. For the branch attributes, refer to the manual in aufs-util.git. Signed-off-by:
J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
Aufs pseudo-link (plink) represents a virtual hardlink across the branches. To implement the plink maintenance mode, aufs uses procfs. See also the document in this commit. There is an external user-space utility called 'auplink' in aufs-util.git, which has these features. - 'list' shows the pseudo-linked inode numbers and filenames. - 'cpup' copies-up all pseudo-link to the writable branch. - 'flush' calls 'cpup', and then 'mount -o remount,clean_plink=inum' Signed-off-by:
J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
The whiteout represents a logical deletion. Although the document in this commit mentioned about rmdir(2) and rename(2) for dir, this commit doesn't contain such functions. They will be added in later commits. 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
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
Aufs uses the workqueue both synchronously and asynchronously. For sync-use-case, aufs uses its own specific wkq since doesn't want to be disturbed by other tasks on the system. For async-use-case, aufs uses the system global workqueue. Aufs has to prevent itself to being unmounted during the async-task is queued. See also the document in this 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>
-
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>
-