aufs: remove support, we need a maintainer for this external patch, anyone?

4 files changed, 0 insertions, 35550 deletions

diff --git a/target/linux/config/Config.in.aufs b/target/linux/config/Config.in.aufs
deleted file mode 100644
index 9c65d37f4..000000000
--- a/target/linux/config/Config.in.aufs
+++ /dev/null
@@ -1,96 +0,0 @@
-# This file is part of the OpenADK project. OpenADK is copyrighted
-# material, please see the LICENCE file in the top-level directory.
-
-menu "Overlay filesystems"
-
-config ADK_KERNEL_AUFS_FS
-	bool "Aufs (Advanced multi layered unification filesystem) support"
-	help
-	  Aufs is a stackable unification filesystem such as Unionfs,
-	  which unifies several directories and provides a merged single
-	  directory.
-	  In the early days, aufs was entirely re-designed and
-	  re-implemented Unionfs Version 1.x series. Introducing many
-	  original ideas, approaches and improvements, it becomes totally
-	  different from Unionfs while keeping the basic features.
-
-if ADK_KERNEL_AUFS_FS
-
-choice 
-	bool "Maximum number of branches"
-	default ADK_KERNEL_AUFS_BRANCH_MAX_127
-	help
-	  Specifies the maximum number of branches (or member directories)
-	  in a single aufs. The larger value consumes more system
-	  resources and has a minor impact to performance.
-
-config ADK_KERNEL_AUFS_BRANCH_MAX_127
-	bool "127"
-
-config ADK_KERNEL_AUFS_BRANCH_MAX_511
-	bool "511"
-
-config ADK_KERNEL_AUFS_BRANCH_MAX_1023
-	bool "1023"
-
-config ADK_KERNEL_AUFS_BRANCH_MAX_32767
-	bool "32767"
-
-endchoice
-
-config ADK_KERNEL_AUFS_HINOTIFY
-	bool "Use inotify to detect actions on a branch"
-	help
-	 If you want to modify files on branches directly, eg. bypassing aufs,
-	 and want aufs to detect the changes of them fully, then enable this
-	 option and use 'udba=inotify' mount option.
-	 It will have a negative impact to the performance.
-	 See detail in aufs.5.
-
-config ADK_KERNEL_AUFS_EXPORT
-	bool "NFS-exportable aufs"
-	select ADK_KERNEL_EXPORTFS
-	help
-	  If you want to export your mounted aufs via NFS, then enable this
-	  option. There are several requirements for this configuration.
-	  See detail in aufs.5.
-
-config ADK_KERNEL_AUFS_SHWH
-	bool "Show whiteouts"
-	help
-	  If you want to make the whiteouts in aufs visible, then enable
-	  this option and specify 'shwh' mount option. Although it may
-	  sounds like philosophy or something, but in technically it
-	  simply shows the name of whiteout with keeping its behaviour.
-
-config ADK_KERNEL_AUFS_BR_RAMFS
-	bool "Ramfs (initramfs/rootfs) as an aufs branch"
-	help
-	  If you want to use ramfs as an aufs branch fs, then enable this
-	  Generally tmpfs is recommended.
-	  hibited them to be a branch fs by default, because
-	  s becomes unusable after switch_root or something
-	  y. If you sets initramfs as an aufs branch and boot your
-	  y switch_root, you will meet a problem easily since the
-	   initramfs may be inaccessible.
-	  ou are going to use ramfs as an aufs branch fs without
-	  oot or something, leave it N.
-
-config ADK_KERNEL_AUFS_BR_FUSE
-	bool "Fuse fs as an aufs branch"
-	select ADK_KERNEL_AUFS_POLL
-	select ADK_KERNEL_FUSE_FS
-	help
-	  If you want to use fuse-based userspace filesystem as an aufs
-	  branch fs, then enable this option.
-	  It implements the internal poll(2) operation which is
-	  implemented by fuse only (curretnly).
-
-#config ADK_KERNEL_AUFS_DEBUG
-#	bool "Debug aufs"
-#	help
-#	  Enable this to compile aufs internal debug code.
-#	  It will have a negative impact to the performance.
-
-endif
-endmenu
diff --git a/target/linux/config/Config.in.fs b/target/linux/config/Config.in.fs
index 71b6ce7fb..622a65363 100644
--- a/target/linux/config/Config.in.fs
+++ b/target/linux/config/Config.in.fs
@@ -263,6 +263,5 @@ endmenu
 source target/linux/config/Config.in.part
 source target/linux/config/Config.in.fsnet
 source target/linux/config/Config.in.nls
-source target/linux/config/Config.in.aufs
 
 endmenu
diff --git a/target/linux/patches/3.4.112/aufs2.patch b/target/linux/patches/3.4.112/aufs2.patch
deleted file mode 100644
index d40c9a3fe..000000000
--- a/target/linux/patches/3.4.112/aufs2.patch
+++ /dev/null
@@ -1,238 +0,0 @@
-diff -Nur linux-3.1.4.orig/include/linux/Kbuild linux-3.1.4/include/linux/Kbuild
---- linux-3.1.4.orig/include/linux/Kbuild	2011-11-28 23:48:14.000000000 +0100
-+++ linux-3.1.4/include/linux/Kbuild	2011-12-01 12:44:17.000000000 +0100
-@@ -65,6 +65,7 @@
- header-y += atmsap.h
- header-y += atmsvc.h
- header-y += audit.h
-+header-y += aufs_type.h
- header-y += auto_fs.h
- header-y += auto_fs4.h
- header-y += auxvec.h
-diff -Nur linux-3.1.4.orig/include/linux/aufs_type.h linux-3.1.4/include/linux/aufs_type.h
---- linux-3.1.4.orig/include/linux/aufs_type.h	1970-01-01 01:00:00.000000000 +0100
-+++ linux-3.1.4/include/linux/aufs_type.h	2011-12-01 12:44:17.000000000 +0100
-@@ -0,0 +1,197 @@
-+/*
-+ * Copyright (C) 2005-2011 Junjiro R. Okajima
-+ *
-+ * This program, aufs is free software; you can redistribute it and/or modify
-+ * it under the terms of the GNU General Public License as published by
-+ * the Free Software Foundation; either version 2 of the License, or
-+ * (at your option) any later version.
-+ *
-+ * This program is distributed in the hope that it will be useful,
-+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
-+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-+ * GNU General Public License for more details.
-+ *
-+ * You should have received a copy of the GNU General Public License
-+ * along with this program; if not, write to the Free Software
-+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
-+ */
-+
-+#ifndef __AUFS_TYPE_H__
-+#define __AUFS_TYPE_H__
-+
-+#include <linux/ioctl.h>
-+#include <linux/kernel.h>
-+#include <linux/limits.h>
-+#include <linux/types.h>
-+
-+#define AUFS_VERSION	"2.1-standalone.tree-36-20110110"
-+
-+/* todo? move this to linux-2.6.19/include/magic.h */
-+#define AUFS_SUPER_MAGIC	('a' << 24 | 'u' << 16 | 'f' << 8 | 's')
-+
-+/* ---------------------------------------------------------------------- */
-+
-+#ifdef CONFIG_AUFS_BRANCH_MAX_127
-+typedef __s8 aufs_bindex_t;
-+#define AUFS_BRANCH_MAX 127
-+#else
-+typedef __s16 aufs_bindex_t;
-+#ifdef CONFIG_AUFS_BRANCH_MAX_511
-+#define AUFS_BRANCH_MAX 511
-+#elif defined(CONFIG_AUFS_BRANCH_MAX_1023)
-+#define AUFS_BRANCH_MAX 1023
-+#elif defined(CONFIG_AUFS_BRANCH_MAX_32767)
-+#define AUFS_BRANCH_MAX 32767
-+#endif
-+#endif
-+
-+#ifdef __KERNEL__
-+#ifndef AUFS_BRANCH_MAX
-+#error unknown CONFIG_AUFS_BRANCH_MAX value
-+#endif
-+#endif /* __KERNEL__ */
-+
-+/* ---------------------------------------------------------------------- */
-+
-+#define AUFS_NAME		"aufs"
-+#define AUFS_FSTYPE		AUFS_NAME
-+
-+#define AUFS_ROOT_INO		2
-+#define AUFS_FIRST_INO		11
-+
-+#define AUFS_WH_PFX		".wh."
-+#define AUFS_WH_PFX_LEN		((int)sizeof(AUFS_WH_PFX) - 1)
-+#define AUFS_WH_TMP_LEN		4
-+/* a limit for rmdir/rename a dir */
-+#define AUFS_MAX_NAMELEN	(NAME_MAX \
-+				- AUFS_WH_PFX_LEN * 2	/* doubly whiteouted */\
-+				- 1			/* dot */\
-+				- AUFS_WH_TMP_LEN)	/* hex */
-+#define AUFS_XINO_FNAME		"." AUFS_NAME ".xino"
-+#define AUFS_XINO_DEFPATH	"/tmp/" AUFS_XINO_FNAME
-+#define AUFS_XINO_TRUNC_INIT	64 /* blocks */
-+#define AUFS_XINO_TRUNC_STEP	4  /* blocks */
-+#define AUFS_DIRWH_DEF		3
-+#define AUFS_RDCACHE_DEF	10 /* seconds */
-+#define AUFS_RDCACHE_MAX	3600 /* seconds */
-+#define AUFS_RDBLK_DEF		512 /* bytes */
-+#define AUFS_RDHASH_DEF		32
-+#define AUFS_WKQ_NAME		AUFS_NAME "d"
-+#define AUFS_WKQ_PRE_NAME	AUFS_WKQ_NAME "_pre"
-+#define AUFS_MFS_DEF_SEC	30 /* seconds */
-+#define AUFS_MFS_MAX_SEC	3600 /* seconds */
-+#define AUFS_PLINK_WARN		100 /* number of plinks */
-+
-+/* pseudo-link maintenace under /proc */
-+#define AUFS_PLINK_MAINT_NAME	"plink_maint"
-+#define AUFS_PLINK_MAINT_DIR	"fs/" AUFS_NAME
-+#define AUFS_PLINK_MAINT_PATH	AUFS_PLINK_MAINT_DIR "/" AUFS_PLINK_MAINT_NAME
-+
-+#define AUFS_DIROPQ_NAME	AUFS_WH_PFX ".opq" /* whiteouted doubly */
-+#define AUFS_WH_DIROPQ		AUFS_WH_PFX AUFS_DIROPQ_NAME
-+
-+#define AUFS_BASE_NAME		AUFS_WH_PFX AUFS_NAME
-+#define AUFS_PLINKDIR_NAME	AUFS_WH_PFX "plnk"
-+#define AUFS_ORPHDIR_NAME	AUFS_WH_PFX "orph"
-+
-+/* doubly whiteouted */
-+#define AUFS_WH_BASE		AUFS_WH_PFX AUFS_BASE_NAME
-+#define AUFS_WH_PLINKDIR	AUFS_WH_PFX AUFS_PLINKDIR_NAME
-+#define AUFS_WH_ORPHDIR		AUFS_WH_PFX AUFS_ORPHDIR_NAME
-+
-+/* branch permission */
-+#define AUFS_BRPERM_RW		"rw"
-+#define AUFS_BRPERM_RO		"ro"
-+#define AUFS_BRPERM_RR		"rr"
-+#define AUFS_BRPERM_WH		"wh"
-+#define AUFS_BRPERM_NLWH	"nolwh"
-+#define AUFS_BRPERM_ROWH	AUFS_BRPERM_RO "+" AUFS_BRPERM_WH
-+#define AUFS_BRPERM_RRWH	AUFS_BRPERM_RR "+" AUFS_BRPERM_WH
-+#define AUFS_BRPERM_RWNLWH	AUFS_BRPERM_RW "+" AUFS_BRPERM_NLWH
-+
-+/* ---------------------------------------------------------------------- */
-+
-+/* ioctl */
-+enum {
-+	/* readdir in userspace */
-+	AuCtl_RDU,
-+	AuCtl_RDU_INO,
-+
-+	/* pathconf wrapper */
-+	AuCtl_WBR_FD
-+};
-+
-+/* borrowed from linux/include/linux/kernel.h */
-+#ifndef ALIGN
-+#define ALIGN(x, a)		__ALIGN_MASK(x, (typeof(x))(a)-1)
-+#define __ALIGN_MASK(x, mask)	(((x)+(mask))&~(mask))
-+#endif
-+
-+/* borrowed from linux/include/linux/compiler-gcc3.h */
-+#ifndef __aligned
-+#define __aligned(x)			__attribute__((aligned(x)))
-+#define __packed			__attribute__((packed))
-+#endif
-+
-+struct au_rdu_cookie {
-+	__u64		h_pos;
-+	__s16		bindex;
-+	__u8		flags;
-+	__u8		pad;
-+	__u32		generation;
-+} __aligned(8);
-+
-+struct au_rdu_ent {
-+	__u64		ino;
-+	__s16		bindex;
-+	__u8		type;
-+	__u8		nlen;
-+	__u8		wh;
-+	char		name[0];
-+} __aligned(8);
-+
-+static inline int au_rdu_len(int nlen)
-+{
-+	/* include the terminating NULL */
-+	return ALIGN(sizeof(struct au_rdu_ent) + nlen + 1,
-+		     sizeof(__u64));
-+}
-+
-+union au_rdu_ent_ul {
-+	struct au_rdu_ent __user	*e;
-+	__u64				ul;
-+};
-+
-+enum {
-+	AufsCtlRduV_SZ,
-+	AufsCtlRduV_End
-+};
-+
-+struct aufs_rdu {
-+	/* input */
-+	union {
-+		__u64		sz;	/* AuCtl_RDU */
-+		__u64		nent;	/* AuCtl_RDU_INO */
-+	};
-+	union au_rdu_ent_ul	ent;
-+	__u16			verify[AufsCtlRduV_End];
-+
-+	/* input/output */
-+	__u32			blk;
-+
-+	/* output */
-+	union au_rdu_ent_ul	tail;
-+	/* number of entries which were added in a single call */
-+	__u64			rent;
-+	__u8			full;
-+	__u8			shwh;
-+
-+	struct au_rdu_cookie	cookie;
-+} __aligned(8);
-+
-+#define AuCtlType		'A'
-+#define AUFS_CTL_RDU		_IOWR(AuCtlType, AuCtl_RDU, struct aufs_rdu)
-+#define AUFS_CTL_RDU_INO	_IOWR(AuCtlType, AuCtl_RDU_INO, struct aufs_rdu)
-+#define AUFS_CTL_WBR_FD		_IO(AuCtlType, AuCtl_WBR_FD)
-+
-+#endif /* __AUFS_TYPE_H__ */
-diff -Nur linux-3.1.4.orig/include/linux/namei.h linux-3.1.4/include/linux/namei.h
---- linux-3.1.4.orig/include/linux/namei.h	2011-11-28 23:48:14.000000000 +0100
-+++ linux-3.1.4/include/linux/namei.h	2011-12-01 12:44:17.000000000 +0100
-@@ -85,6 +85,9 @@
- extern struct file *lookup_instantiate_filp(struct nameidata *nd, struct dentry *dentry,
- 		int (*open)(struct inode *, struct file *));
- 
-+extern struct dentry *lookup_hash(struct nameidata *nd);
-+extern int __lookup_one_len(const char *name, struct qstr *this,
-+			    struct dentry *base, int len);
- extern struct dentry *lookup_one_len(const char *, struct dentry *, int);
- 
- extern int follow_down_one(struct path *);
-diff -Nur linux-3.1.4.orig/include/linux/splice.h linux-3.1.4/include/linux/splice.h
---- linux-3.1.4.orig/include/linux/splice.h	2011-11-28 23:48:14.000000000 +0100
-+++ linux-3.1.4/include/linux/splice.h	2011-12-01 12:45:51.000000000 +0100
-@@ -91,4 +91,9 @@
- extern void spd_release_page(struct splice_pipe_desc *, unsigned int);
- 
- extern const struct pipe_buf_operations page_cache_pipe_buf_ops;
-+extern long do_splice_from(struct pipe_inode_info *pipe, struct file *out,
-+			   loff_t *ppos, size_t len, unsigned int flags);
-+extern long do_splice_to(struct file *in, loff_t *ppos,
-+			 struct pipe_inode_info *pipe, size_t len,
-+			 unsigned int flags);
- #endif
diff --git a/target/linux/patches/4.1.30/aufs.patch b/target/linux/patches/4.1.30/aufs.patch
deleted file mode 100644
index 749c90989..000000000
--- a/target/linux/patches/4.1.30/aufs.patch
+++ /dev/null
@@ -1,35215 +0,0 @@
-diff -Nur linux-4.1.10.orig/Documentation/ABI/testing/debugfs-aufs linux-4.1.10/Documentation/ABI/testing/debugfs-aufs
---- linux-4.1.10.orig/Documentation/ABI/testing/debugfs-aufs	1970-01-01 01:00:00.000000000 +0100
-+++ linux-4.1.10/Documentation/ABI/testing/debugfs-aufs	2015-10-22 21:35:53.000000000 +0200
-@@ -0,0 +1,50 @@
-+What:		/debug/aufs/si_<id>/
-+Date:		March 2009
-+Contact:	J. R. Okajima <hooanon05g@gmail.com>
-+Description:
-+		Under /debug/aufs, a directory named si_<id> is created
-+		per aufs mount, where <id> is a unique id generated
-+		internally.
-+
-+What:		/debug/aufs/si_<id>/plink
-+Date:		Apr 2013
-+Contact:	J. R. Okajima <hooanon05g@gmail.com>
-+Description:
-+		It has three lines and shows the information about the
-+		pseudo-link. The first line is a single number
-+		representing a number of buckets. The second line is a
-+		number of pseudo-links per buckets (separated by a
-+		blank). The last line is a single number representing a
-+		total number of psedo-links.
-+		When the aufs mount option 'noplink' is specified, it
-+		will show "1\n0\n0\n".
-+
-+What:		/debug/aufs/si_<id>/xib
-+Date:		March 2009
-+Contact:	J. R. Okajima <hooanon05g@gmail.com>
-+Description:
-+		It shows the consumed blocks by xib (External Inode Number
-+		Bitmap), its block size and file size.
-+		When the aufs mount option 'noxino' is specified, it
-+		will be empty. About XINO files, see the aufs manual.
-+
-+What:		/debug/aufs/si_<id>/xino0, xino1 ... xinoN
-+Date:		March 2009
-+Contact:	J. R. Okajima <hooanon05g@gmail.com>
-+Description:
-+		It shows the consumed blocks by xino (External Inode Number
-+		Translation Table), its link count, block size and file
-+		size.
-+		When the aufs mount option 'noxino' is specified, it
-+		will be empty. About XINO files, see the aufs manual.
-+
-+What:		/debug/aufs/si_<id>/xigen
-+Date:		March 2009
-+Contact:	J. R. Okajima <hooanon05g@gmail.com>
-+Description:
-+		It shows the consumed blocks by xigen (External Inode
-+		Generation Table), its block size and file size.
-+		If CONFIG_AUFS_EXPORT is disabled, this entry will not
-+		be created.
-+		When the aufs mount option 'noxino' is specified, it
-+		will be empty. About XINO files, see the aufs manual.
-diff -Nur linux-4.1.10.orig/Documentation/ABI/testing/sysfs-aufs linux-4.1.10/Documentation/ABI/testing/sysfs-aufs
---- linux-4.1.10.orig/Documentation/ABI/testing/sysfs-aufs	1970-01-01 01:00:00.000000000 +0100
-+++ linux-4.1.10/Documentation/ABI/testing/sysfs-aufs	2015-10-22 21:35:53.000000000 +0200
-@@ -0,0 +1,31 @@
-+What:		/sys/fs/aufs/si_<id>/
-+Date:		March 2009
-+Contact:	J. R. Okajima <hooanon05g@gmail.com>
-+Description:
-+		Under /sys/fs/aufs, a directory named si_<id> is created
-+		per aufs mount, where <id> is a unique id generated
-+		internally.
-+
-+What:		/sys/fs/aufs/si_<id>/br0, br1 ... brN
-+Date:		March 2009
-+Contact:	J. R. Okajima <hooanon05g@gmail.com>
-+Description:
-+		It shows the abolute path of a member directory (which
-+		is called branch) in aufs, and its permission.
-+
-+What:		/sys/fs/aufs/si_<id>/brid0, brid1 ... bridN
-+Date:		July 2013
-+Contact:	J. R. Okajima <hooanon05g@gmail.com>
-+Description:
-+		It shows the id of a member directory (which is called
-+		branch) in aufs.
-+
-+What:		/sys/fs/aufs/si_<id>/xi_path
-+Date:		March 2009
-+Contact:	J. R. Okajima <hooanon05g@gmail.com>
-+Description:
-+		It shows the abolute path of XINO (External Inode Number
-+		Bitmap, Translation Table and Generation Table) file
-+		even if it is the default path.
-+		When the aufs mount option 'noxino' is specified, it
-+		will be empty. About XINO files, see the aufs manual.
-diff -Nur linux-4.1.10.orig/Documentation/filesystems/aufs/design/01intro.txt linux-4.1.10/Documentation/filesystems/aufs/design/01intro.txt
---- linux-4.1.10.orig/Documentation/filesystems/aufs/design/01intro.txt	1970-01-01 01:00:00.000000000 +0100
-+++ linux-4.1.10/Documentation/filesystems/aufs/design/01intro.txt	2015-10-22 21:35:53.000000000 +0200
-@@ -0,0 +1,170 @@
-+
-+# Copyright (C) 2005-2015 Junjiro R. Okajima
-+# 
-+# This program is free software; you can redistribute it and/or modify
-+# it under the terms of the GNU General Public License as published by
-+# the Free Software Foundation; either version 2 of the License, or
-+# (at your option) any later version.
-+# 
-+# This program is distributed in the hope that it will be useful,
-+# but WITHOUT ANY WARRANTY; without even the implied warranty of
-+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-+# GNU General Public License for more details.
-+# 
-+# You should have received a copy of the GNU General Public License
-+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
-+
-+Introduction
-+----------------------------------------
-+
-+aufs [ei ju: ef es] | [a u f s]
-+1. abbrev. for "advanced multi-layered unification filesystem".
-+2. abbrev. for "another unionfs".
-+3. abbrev. for "auf das" in German which means "on the" in English.
-+   Ex. "Butter aufs Brot"(G) means "butter onto bread"(E).
-+   But "Filesystem aufs Filesystem" is hard to understand.
-+
-+AUFS is a filesystem with features:
-+- multi layered stackable unification filesystem, the member directory
-+  is called as a branch.
-+- branch permission and attribute, 'readonly', 'real-readonly',
-+  'readwrite', 'whiteout-able', 'link-able whiteout', etc. and their
-+  combination.
-+- internal "file copy-on-write".
-+- logical deletion, whiteout.
-+- dynamic branch manipulation, adding, deleting and changing permission.
-+- allow bypassing aufs, user's direct branch access.
-+- external inode number translation table and bitmap which maintains the
-+  persistent aufs inode number.
-+- seekable directory, including NFS readdir.
-+- file mapping, mmap and sharing pages.
-+- pseudo-link, hardlink over branches.
-+- loopback mounted filesystem as a branch.
-+- several policies to select one among multiple writable branches.
-+- revert a single systemcall when an error occurs in aufs.
-+- and more...
-+
-+
-+Multi Layered Stackable Unification Filesystem
-+----------------------------------------------------------------------
-+Most people already knows what it is.
-+It is a filesystem which unifies several directories and provides a
-+merged single directory. When users access a file, the access will be
-+passed/re-directed/converted (sorry, I am not sure which English word is
-+correct) to the real file on the member filesystem. The member
-+filesystem is called 'lower filesystem' or 'branch' and has a mode
-+'readonly' and 'readwrite.' And the deletion for a file on the lower
-+readonly branch is handled by creating 'whiteout' on the upper writable
-+branch.
-+
-+On LKML, there have been discussions about UnionMount (Jan Blunck,
-+Bharata B Rao and Valerie Aurora) and Unionfs (Erez Zadok). They took
-+different approaches to implement the merged-view.
-+The former tries putting it into VFS, and the latter implements as a
-+separate filesystem.
-+(If I misunderstand about these implementations, please let me know and
-+I shall correct it. Because it is a long time ago when I read their
-+source files last time).
-+
-+UnionMount's approach will be able to small, but may be hard to share
-+branches between several UnionMount since the whiteout in it is
-+implemented in the inode on branch filesystem and always
-+shared. According to Bharata's post, readdir does not seems to be
-+finished yet.
-+There are several missing features known in this implementations such as
-+- for users, the inode number may change silently. eg. copy-up.
-+- link(2) may break by copy-up.
-+- read(2) may get an obsoleted filedata (fstat(2) too).
-+- fcntl(F_SETLK) may be broken by copy-up.
-+- unnecessary copy-up may happen, for example mmap(MAP_PRIVATE) after
-+  open(O_RDWR).
-+
-+In linux-3.18, "overlay" filesystem (formerly known as "overlayfs") was
-+merged into mainline. This is another implementation of UnionMount as a
-+separated filesystem. All the limitations and known problems which
-+UnionMount are equally inherited to "overlay" filesystem.
-+
-+Unionfs has a longer history. When I started implementing a stackable
-+filesystem (Aug 2005), it already existed. It has virtual super_block,
-+inode, dentry and file objects and they have an array pointing lower
-+same kind objects. After contributing many patches for Unionfs, I
-+re-started my project AUFS (Jun 2006).
-+
-+In AUFS, the structure of filesystem resembles to Unionfs, but I
-+implemented my own ideas, approaches and enhancements and it became
-+totally different one.
-+
-+Comparing DM snapshot and fs based implementation
-+- the number of bytes to be copied between devices is much smaller.
-+- the type of filesystem must be one and only.
-+- the fs must be writable, no readonly fs, even for the lower original
-+  device. so the compression fs will not be usable. but if we use
-+  loopback mount, we may address this issue.
-+  for instance,
-+	mount /cdrom/squashfs.img /sq
-+	losetup /sq/ext2.img
-+	losetup /somewhere/cow
-+	dmsetup "snapshot /dev/loop0 /dev/loop1 ..."
-+- it will be difficult (or needs more operations) to extract the
-+  difference between the original device and COW.
-+- DM snapshot-merge may help a lot when users try merging. in the
-+  fs-layer union, users will use rsync(1).
-+
-+You may want to read my old paper "Filesystems in LiveCD"
-+(http://aufs.sourceforge.net/aufs2/report/sq/sq.pdf).
-+
-+
-+Several characters/aspects/persona of aufs
-+----------------------------------------------------------------------
-+
-+Aufs has several characters, aspects or persona.
-+1. a filesystem, callee of VFS helper
-+2. sub-VFS, caller of VFS helper for branches
-+3. a virtual filesystem which maintains persistent inode number
-+4. reader/writer of files on branches such like an application
-+
-+1. Callee of VFS Helper
-+As an ordinary linux filesystem, aufs is a callee of VFS. For instance,
-+unlink(2) from an application reaches sys_unlink() kernel function and
-+then vfs_unlink() is called. vfs_unlink() is one of VFS helper and it
-+calls filesystem specific unlink operation. Actually aufs implements the
-+unlink operation but it behaves like a redirector.
-+
-+2. Caller of VFS Helper for Branches
-+aufs_unlink() passes the unlink request to the branch filesystem as if
-+it were called from VFS. So the called unlink operation of the branch
-+filesystem acts as usual. As a caller of VFS helper, aufs should handle
-+every necessary pre/post operation for the branch filesystem.
-+- acquire the lock for the parent dir on a branch
-+- lookup in a branch
-+- revalidate dentry on a branch
-+- mnt_want_write() for a branch
-+- vfs_unlink() for a branch
-+- mnt_drop_write() for a branch
-+- release the lock on a branch
-+
-+3. Persistent Inode Number
-+One of the most important issue for a filesystem is to maintain inode
-+numbers. This is particularly important to support exporting a
-+filesystem via NFS. Aufs is a virtual filesystem which doesn't have a
-+backend block device for its own. But some storage is necessary to
-+keep and maintain the inode numbers. It may be a large space and may not
-+suit to keep in memory. Aufs rents some space from its first writable
-+branch filesystem (by default) and creates file(s) on it. These files
-+are created by aufs internally and removed soon (currently) keeping
-+opened.
-+Note: Because these files are removed, they are totally gone after
-+      unmounting aufs. It means the inode numbers are not persistent
-+      across unmount or reboot. I have a plan to make them really
-+      persistent which will be important for aufs on NFS server.
-+
-+4. Read/Write Files Internally (copy-on-write)
-+Because a branch can be readonly, when you write a file on it, aufs will
-+"copy-up" it to the upper writable branch internally. And then write the
-+originally requested thing to the file. Generally kernel doesn't
-+open/read/write file actively. In aufs, even a single write may cause a
-+internal "file copy". This behaviour is very similar to cp(1) command.
-+
-+Some people may think it is better to pass such work to user space
-+helper, instead of doing in kernel space. Actually I am still thinking
-+about it. But currently I have implemented it in kernel space.
-diff -Nur linux-4.1.10.orig/Documentation/filesystems/aufs/design/02struct.txt linux-4.1.10/Documentation/filesystems/aufs/design/02struct.txt
---- linux-4.1.10.orig/Documentation/filesystems/aufs/design/02struct.txt	1970-01-01 01:00:00.000000000 +0100
-+++ linux-4.1.10/Documentation/filesystems/aufs/design/02struct.txt	2015-10-22 21:35:53.000000000 +0200
-@@ -0,0 +1,258 @@
-+
-+# Copyright (C) 2005-2015 Junjiro R. Okajima
-+# 
-+# This program is free software; you can redistribute it and/or modify
-+# it under the terms of the GNU General Public License as published by
-+# the Free Software Foundation; either version 2 of the License, or
-+# (at your option) any later version.
-+# 
-+# This program is distributed in the hope that it will be useful,
-+# but WITHOUT ANY WARRANTY; without even the implied warranty of
-+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-+# GNU General Public License for more details.
-+# 
-+# You should have received a copy of the GNU General Public License
-+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
-+
-+Basic Aufs Internal Structure
-+
-+Superblock/Inode/Dentry/File Objects
-+----------------------------------------------------------------------
-+As like an ordinary filesystem, aufs has its own
-+superblock/inode/dentry/file objects. All these objects have a
-+dynamically allocated array and store the same kind of pointers to the
-+lower filesystem, branch.
-+For example, when you build a union with one readwrite branch and one
-+readonly, mounted /au, /rw and /ro respectively.
-+- /au = /rw + /ro
-+- /ro/fileA exists but /rw/fileA
-+
-+Aufs lookup operation finds /ro/fileA and gets dentry for that. These
-+pointers are stored in a aufs dentry. The array in aufs dentry will be,
-+- [0] = NULL (because /rw/fileA doesn't exist)
-+- [1] = /ro/fileA
-+
-+This style of an array is essentially same to the aufs
-+superblock/inode/dentry/file objects.
-+
-+Because aufs supports manipulating branches, ie. add/delete/change
-+branches dynamically, these objects has its own generation. When
-+branches are changed, the generation in aufs superblock is
-+incremented. And a generation in other object are compared when it is
-+accessed. When a generation in other objects are obsoleted, aufs
-+refreshes the internal array.
-+
-+
-+Superblock
-+----------------------------------------------------------------------
-+Additionally aufs superblock has some data for policies to select one
-+among multiple writable branches, XIB files, pseudo-links and kobject.
-+See below in detail.
-+About the policies which supports copy-down a directory, see
-+wbr_policy.txt too.
-+
-+
-+Branch and XINO(External Inode Number Translation Table)
-+----------------------------------------------------------------------
-+Every branch has its own xino (external inode number translation table)
-+file. The xino file is created and unlinked by aufs internally. When two
-+members of a union exist on the same filesystem, they share the single
-+xino file.
-+The struct of a xino file is simple, just a sequence of aufs inode
-+numbers which is indexed by the lower inode number.
-+In the above sample, assume the inode number of /ro/fileA is i111 and
-+aufs assigns the inode number i999 for fileA. Then aufs writes 999 as
-+4(8) bytes at 111 * 4(8) bytes offset in the xino file.
-+
-+When the inode numbers are not contiguous, the xino file will be sparse
-+which has a hole in it and doesn't consume as much disk space as it
-+might appear. If your branch filesystem consumes disk space for such
-+holes, then you should specify 'xino=' option at mounting aufs.
-+
-+Aufs has a mount option to free the disk blocks for such holes in XINO
-+files on tmpfs or ramdisk. But it is not so effective actually. If you
-+meet a problem of disk shortage due to XINO files, then you should try
-+"tmpfs-ino.patch" (and "vfs-ino.patch" too) in aufs4-standalone.git.
-+The patch localizes the assignment inumbers per tmpfs-mount and avoid
-+the holes in XINO files.
-+
-+Also a writable branch has three kinds of "whiteout bases". All these
-+are existed when the branch is joined to aufs, and their names are
-+whiteout-ed doubly, so that users will never see their names in aufs
-+hierarchy.
-+1. a regular file which will be hardlinked to all whiteouts.
-+2. a directory to store a pseudo-link.
-+3. a directory to store an "orphan"-ed file temporary.
-+
-+1. Whiteout Base
-+   When you remove a file on a readonly branch, aufs handles it as a
-+   logical deletion and creates a whiteout on the upper writable branch
-+   as a hardlink of this file in order not to consume inode on the
-+   writable branch.
-+2. Pseudo-link Dir
-+   See below, Pseudo-link.
-+3. Step-Parent Dir
-+   When "fileC" exists on the lower readonly branch only and it is
-+   opened and removed with its parent dir, and then user writes
-+   something into it, then aufs copies-up fileC to this
-+   directory. Because there is no other dir to store fileC. After
-+   creating a file under this dir, the file is unlinked.
-+
-+Because aufs supports manipulating branches, ie. add/delete/change
-+dynamically, a branch has its own id. When the branch order changes,
-+aufs finds the new index by searching the branch id.
-+
-+
-+Pseudo-link
-+----------------------------------------------------------------------
-+Assume "fileA" exists on the lower readonly branch only and it is
-+hardlinked to "fileB" on the branch. When you write something to fileA,
-+aufs copies-up it to the upper writable branch. Additionally aufs
-+creates a hardlink under the Pseudo-link Directory of the writable
-+branch. The inode of a pseudo-link is kept in aufs super_block as a
-+simple list. If fileB is read after unlinking fileA, aufs returns
-+filedata from the pseudo-link instead of the lower readonly
-+branch. Because the pseudo-link is based upon the inode, to keep the
-+inode number by xino (see above) is essentially necessary.
-+
-+All the hardlinks under the Pseudo-link Directory of the writable branch
-+should be restored in a proper location later. Aufs provides a utility
-+to do this. The userspace helpers executed at remounting and unmounting
-+aufs by default.
-+During this utility is running, it puts aufs into the pseudo-link
-+maintenance mode. In this mode, only the process which began the
-+maintenance mode (and its child processes) is allowed to operate in
-+aufs. Some other processes which are not related to the pseudo-link will
-+be allowed to run too, but the rest have to return an error or wait
-+until the maintenance mode ends. If a process already acquires an inode
-+mutex (in VFS), it has to return an error.
-+
-+
-+XIB(external inode number bitmap)
-+----------------------------------------------------------------------
-+Addition to the xino file per a branch, aufs has an external inode number
-+bitmap in a superblock object. It is also an internal file such like a
-+xino file.
-+It is a simple bitmap to mark whether the aufs inode number is in-use or
-+not.
-+To reduce the file I/O, aufs prepares a single memory page to cache xib.
-+
-+As well as XINO files, aufs has a feature to truncate/refresh XIB to
-+reduce the number of consumed disk blocks for these files.
-+
-+
-+Virtual or Vertical Dir, and Readdir in Userspace
-+----------------------------------------------------------------------
-+In order to support multiple layers (branches), aufs readdir operation
-+constructs a virtual dir block on memory. For readdir, aufs calls
-+vfs_readdir() internally for each dir on branches, merges their entries
-+with eliminating the whiteout-ed ones, and sets it to file (dir)
-+object. So the file object has its entry list until it is closed. The
-+entry list will be updated when the file position is zero and becomes
-+obsoleted. This decision is made in aufs automatically.
-+
-+The dynamically allocated memory block for the name of entries has a
-+unit of 512 bytes (by default) and stores the names contiguously (no
-+padding). Another block for each entry is handled by kmem_cache too.
-+During building dir blocks, aufs creates hash list and judging whether
-+the entry is whiteouted by its upper branch or already listed.
-+The merged result is cached in the corresponding inode object and
-+maintained by a customizable life-time option.
-+
-+Some people may call it can be a security hole or invite DoS attack
-+since the opened and once readdir-ed dir (file object) holds its entry
-+list and becomes a pressure for system memory. But I'd say it is similar
-+to files under /proc or /sys. The virtual files in them also holds a
-+memory page (generally) while they are opened. When an idea to reduce
-+memory for them is introduced, it will be applied to aufs too.
-+For those who really hate this situation, I've developed readdir(3)
-+library which operates this merging in userspace. You just need to set
-+LD_PRELOAD environment variable, and aufs will not consume no memory in
-+kernel space for readdir(3).
-+
-+
-+Workqueue
-+----------------------------------------------------------------------
-+Aufs sometimes requires privilege access to a branch. For instance,
-+in copy-up/down operation. When a user process is going to make changes
-+to a file which exists in the lower readonly branch only, and the mode
-+of one of ancestor directories may not be writable by a user
-+process. Here aufs copy-up the file with its ancestors and they may
-+require privilege to set its owner/group/mode/etc.
-+This is a typical case of a application character of aufs (see
-+Introduction).
-+
-+Aufs uses workqueue synchronously for this case. It creates its own
-+workqueue. The workqueue is a kernel thread and has privilege. Aufs
-+passes the request to call mkdir or write (for example), and wait for
-+its completion. This approach solves a problem of a signal handler
-+simply.
-+If aufs didn't adopt the workqueue and changed the privilege of the
-+process, then the process may receive the unexpected SIGXFSZ or other
-+signals.
-+
-+Also aufs uses the system global workqueue ("events" kernel thread) too
-+for asynchronous tasks, such like handling inotify/fsnotify, re-creating a
-+whiteout base and etc. This is unrelated to a privilege.
-+Most of aufs operation tries acquiring a rw_semaphore for aufs
-+superblock at the beginning, at the same time waits for the completion
-+of all queued asynchronous tasks.
-+
-+
-+Whiteout
-+----------------------------------------------------------------------
-+The whiteout in aufs is very similar to Unionfs's. That is represented
-+by its filename. UnionMount takes an approach of a file mode, but I am
-+afraid several utilities (find(1) or something) will have to support it.
-+
-+Basically the whiteout represents "logical deletion" which stops aufs to
-+lookup further, but also it represents "dir is opaque" which also stop
-+further lookup.
-+
-+In aufs, rmdir(2) and rename(2) for dir uses whiteout alternatively.
-+In order to make several functions in a single systemcall to be
-+revertible, aufs adopts an approach to rename a directory to a temporary
-+unique whiteouted name.
-+For example, in rename(2) dir where the target dir already existed, aufs
-+renames the target dir to a temporary unique whiteouted name before the
-+actual rename on a branch, and then handles other actions (make it opaque,
-+update the attributes, etc). If an error happens in these actions, aufs
-+simply renames the whiteouted name back and returns an error. If all are
-+succeeded, aufs registers a function to remove the whiteouted unique
-+temporary name completely and asynchronously to the system global
-+workqueue.
-+
-+
-+Copy-up
-+----------------------------------------------------------------------
-+It is a well-known feature or concept.
-+When user modifies a file on a readonly branch, aufs operate "copy-up"
-+internally and makes change to the new file on the upper writable branch.
-+When the trigger systemcall does not update the timestamps of the parent
-+dir, aufs reverts it after copy-up.
-+
-+
-+Move-down (aufs3.9 and later)
-+----------------------------------------------------------------------
-+"Copy-up" is one of the essential feature in aufs. It copies a file from
-+the lower readonly branch to the upper writable branch when a user
-+changes something about the file.
-+"Move-down" is an opposite action of copy-up. Basically this action is
-+ran manually instead of automatically and internally.
-+For desgin and implementation, aufs has to consider these issues.
-+- whiteout for the file may exist on the lower branch.
-+- ancestor directories may not exist on the lower branch.
-+- diropq for the ancestor directories may exist on the upper branch.
-+- free space on the lower branch will reduce.
-+- another access to the file may happen during moving-down, including
-+  UDBA (see "Revalidate Dentry and UDBA").
-+- the file should not be hard-linked nor pseudo-linked. they should be
-+  handled by auplink utility later.
-+
-+Sometimes users want to move-down a file from the upper writable branch
-+to the lower readonly or writable branch. For instance,
-+- the free space of the upper writable branch is going to run out.
-+- create a new intermediate branch between the upper and lower branch.
-+- e