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 -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
