On Thu, Apr 6, 2017 at 5:20 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > On Thu, Mar 30, 2017 at 1:34 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > Simplest solution is to keep mapping in the upper inode itself > (xattr). Takes care of removal automatically. Can be cached in > ovl_entry. Makes readdir() really inefficient... need to cache > whether mapping needed for any directory entries in directory, which > complicates rename. > > 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 > in the map and setting the bit for those. Then only reach out to the > disk db if there's a possibility of hit. Would still need to design > an efficient way to store and access the data in the db (and I have > zero experience with that sort of thing). Hmm, could actually combine the two ideas: Store mapping just in upper inode, walk upper tree on mount and fill in bitmap. Update bitmap as we go. Reverse mapping still needs out-of-band solution, since walking the whole upper tree each time we need to find a reverse map doesn't look like a good solution. Thanks, Miklos > > Thoughts? > > Thanks, > Miklos -- 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
