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

[Pavel Emelyanov]

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.

-- Pavel