Re: [PATCH 0/6] ovl: consistent_fd feature

["J. R. Okajima" <hooanon05g@gmail.com>]

Miklos Szeredi:
> The other idea is to store the database separately from the upper tree
> (this is what aufs does, apparently).  This works for reverse mapping
> as well.  Makes all operations (except rename) more complicated.
> Keeping whole mapping in kernel memory is prone to resource hogging
> and DoS.   Could have a bitmap created by hashing the ino's that are
	:::

I am afraid you are misunderstanding a little.
Aufs XINO (external inode number translation table) is a simple regular
file.
- created and unlinked in mounting aufs, kept in-use.
- the default path is "<first writable layer>/.aufs.xino".
- users can change the path by a mount option "xino=..."
- users can change the path on the fly by remounting anytime.
- users can stop using XINO by a mount/remount option "noxino"

It should not be a kernel memory pressure (unless users put XINO on
tmpfs or something).

XINO is not a so complicated operation. Receiving the inum on the layer
fs, returns the aufs inum. Its maintenance simply follows the lifetime of
aufs inode.
- in creating aufs inode, the mapping of the layer fs inum and the aufs
  inum is added.
- in destroying aufs inode, if the link count of the layer fs inode is
  zero, then the mapping is removed.
- in copy-up, the mapping is added obviously.


J. R. Okajima