On Thu, Sep 25, 2014 at 10:30:10AM +0200, Jan Kara wrote: > On Wed 24-09-14 13:19:47, Andrew Morton wrote: > > On Wed, 24 Sep 2014 12:51:55 +0200 Jan Kara <jack@xxxxxxx> wrote: > > > > > Hello, > > > > > > Andrew, what do you think about the patch below? Al objected that it > > > changes userspace visible behavior some time ago and then he didn't react > > > to our explanations... > > > > Difficult situation. There's some really important information missing > > from the changelog: > > > > - Who cares? Is there some real application which is hurting from > > the current situation? If so, who, what, how and why. If not, then > > why change anything? > I believe Openvz guys hit this in their application but I'll defer to > them for more details. Hi, sorry for delay! Indeed we found this weird behaviour while been testing the results of restore of deleted files. When criu observes opened descriptor on deleted file its contents get written into criu image file which we call "ghost" files. On restore we create a temporary ghost file with some unique name. Then we restore file descriptors which were opened at the moment of checkpoint: we create a hardlink to this ghost file, then open it and this is done for every descriptor we need to recover. Then if there were a watch mark on the ghost file we restore them as well but at the end we need to do a cleanup and finally remove the ghost file itself which cause the problem mentioned in Andrew's changelog to appear -- when we remove ghost file inode->n_link becomes 0 thus our restored inotify are dropped off by the kernel while here still opened files are floating around. I can't say that it's catastrophical but if there a chance to fix it on kernel level making events flow more sane, this would be just great, also our primary target is to make c/r process transparent to the userspace and without the patch i fear we can't reach it. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
