[CRIU] irmap: Can't stat /no-such-path: No such file or directory

[Tycho Andersen]

On Tue, Sep 08, 2015 at 05:34:47PM +0300, Pavel Emelyanov wrote:
> On 09/08/2015 04:47 PM, Tycho Andersen wrote:
> 
> >>> http://paste.ubuntu.com/12279228/
> >>>
> >>> It seems to me like we shouldn't be trying to stat no-such-path, but
> >>> that seems like the symptom of a larger problem which is that we can't
> >>> otherwise resolve the handle.
> >>>
> >>> I resolved the inode using debugfs, and it says it's /var/log in the
> >>> container, which is not one of our heuristic paths we check:
> >>>
> >>> # debugfs -R 'ncheck 525799' /dev/vda1
> >>> debugfs 1.42.12 (29-Aug-2014)
> >>> Inode Pathname
> >>> 525799  /var/lib/lxd/containers/unpriv/rootfs/var/log
> >>>
> >>> If I add this path (and several others, see the attached patch) to the
> >>> list of irmap hints, it works fine. Obviously this isn't sustainable
> >>> though; is there some nicer solution to this?
> >>
> >> Well, right now we don't have any :( The problem here is that *notify
> >> objects are assigned on inode and kernel can drop all the path information
> >> from it. So once we meet an *notified inode we _try_ to ask kernel for
> >> path and, if it fails, have no other ways to resolve it back.
> > 
> > Hmm, ok. Can we not ask debugfs like I did above? Or is it possible
> > that debugfs would also not know?
> 
> Debugfs would also do what we do in irmap -- it will scan the paths
> from root comparing the inode numbers. But unlike debugfs irmap scans
> the tree only ones keeping the path-to-inode mappings, so it (in
> theory) can be asked several times.
>
> > I can see two potential solutions in that case: 1. we could just
> > hardcode these paths (as they're needed by systemd bits) or 2. we
> > could add a --irmap-path argument, to allow users to specify which
> > paths are interesting and need to be checked. I'm happy to send a
> > patch for whatever you think is appropriate.
> 
> An option would be good :) But the paths are better to eventually be
> shared between you, us and others, so they will slowly get hardcoded
> into irmap-cache.c.

What about another option, --irmap-deep-scan which sets /.'s nr_kids
to -1, so that the whole fs will be scanned if there is one of these
unknown paths? If we take the initial patch I posted, things will
still be fast for current systemd, but with --irmap-deep-scan a dump
will still succeed, it will just be slower.

We can have --irmap-deep-scan print out a warning recommending that
any new path potentially be added to the hardcoded list if it is
system wide?

Tycho