On Tue, Aug 16, 2016 at 5:43 AM, oc <oc@xxxxxxxxxx> wrote: > Hi Vito, [Please refrain from top posting, restored] > 在 2016年08月16日 08:14, Vito Caputo 写道: >> >> Miklos, >> >> Sure, I think the approach of returning the lower layer's ino/dev >> combination for merged directories should be ok? >> >> I guess the one somewhat unexpected behavior/potential down side is >> st_dev spuriously being different within an overlayfs mount point, >> things like `find -xdev` or `du -x` won't recurse into directories on >> the upper layer. Argh, true. >> The advantage of the copying up the directory on >> getattr was it gave all the directories in the overlay unique inode >> numbers within a single device. Yes, directory copy-up on getattr (or lookup) may be the best overall solution. I'd do that optionally, and leave copy-up on write the default as it seems to be OK for most people. > I am working on solving problem when live migrating container on overlayfs, > and it may also affect > to your case: > When live migrating container, either lxc or docker, it use criu to dump the > process. > If the process has inotify entry (with the pending fix 0955793 in Miklos > mail), criu need to find the > file path to inode of inofity entry from scanning files to compare inode in > order to get the file path. It > is described in https://criu.org/Irmap. Since inofity entry's inode is the > one for real directory, probably the > the upper layer, overlayfs need to return the real inode to get criu > working. I think overlayfs needs sb->s_export_op filled in. Together with the overlayfs fsnotify fix that can ensure that fdinfo will contain a fhandle consistent with what stat(2) returns, whathever it is. And AFAICS that is what lrmap needs to get from a notify handle to a path. 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
