[CRIU] [PATCH] mount: Create target of bind mount if it doesn't exist
Tycho Andersen
tycho.andersen at canonical.com
Fri Aug 29 07:15:19 PDT 2014
Hi Pavel,
On Fri, Aug 29, 2014 at 05:59:01PM +0400, Pavel Emelyanov wrote:
> On 08/29/2014 05:48 PM, Tycho Andersen wrote:
> > Hi Pavel,
> >
> > On Fri, Aug 29, 2014 at 04:40:38PM +0400, Pavel Emelyanov wrote:
> >> On 08/28/2014 08:17 PM, Tycho Andersen wrote:
> >>> On Thu, Aug 28, 2014 at 08:07:06PM +0400, Pavel Emelyanov wrote:
> >>>> On 08/28/2014 07:43 PM, Saied Kazemi wrote:
> >>>>> I have seen a similar case where /dev/null is missing (Docker using UnionFS). While this patch fixes
> >>>>> the issue, I am wondering why the target file should be missing to start with and whether *always*
> >>>>> recreating missing target files could be masking more serious issues. Any thoughts?
> >>>>
> >>>> +1 I'd also like to know the reasons why the mountpoint target doesn't exist.
> >>>> AFAIK rmdir/unlink doesn't work on dirs/files that are mountpoints.
> >>>
> >>> They don't exist because rsync doesn't sync them :). What I'm doing
> >>> here is dumping a container, rsyncing over its rootfs and the criu
> >>> output, and then trying to restore it on another host.
> >>
> >> Are you trying to do live migration? :) Would you consider using the
> >> p.haul stuff [1] we've pre-implemented to demonstrate how it can look
> >> like. We don't yet have it in perfect shape, but we plan to make it
> >> our default live-migration engine.
> >
> > Yes, exactly.
> >
> >> [1] https://github.com/xemul/p.haul
> >
> > This looks interesting! I looked at the lxc driver, and it looks like
> > most of what it is doing is saving the veths (and I guess some cg
> > stuff, which isn't needed any more).
>
> The lxc driver was just an example. I was planning, that these "drivers"
> will not become part of the p.haul, but would rather be provided by
> whoever is willing to use p.haul for live migration.
>
> > The patch I just sent to lxc upstream [1] does save this info.
> >
> > In any case, I was hoping that CRIU would take care of all of the gory
> > bits, and all that would be needed is essentially what's already in
> > lxc-checkpoint (and some fancy rsyncing or whatever, which may go in
> > p.haul or a similar tool). Is that your view of things too?
>
> Partially. The thing is -- CRIU takes care of taking the snapshot and
> restoring from one. And as you noticed, it has quite a lot of options
> of how to do it. That's because taking a snapshot for e.g. suspend is
> not the same as taking snapshot for live-migration. In the latter case
> we can do TCP sockets migration, which is impossible in the former.
> And there are more scenarios other than live migration when one might
> need a snapshot.
>
> Moreover, live migration is not just "snapshot, copy, restore". We can
> do memory pre-migration, we should as well take case of the filesystem
> (e.g. there might be no need in rsync if we have a shared FS, in case
> we're running container on virtual block device coping it is better to
> be done w/o rsync, but on the blocks level).
Yep, understood. I'm not trying to build anything that fancy; mostly
I'm just trying this rsync trick to understand what is necessary to
migrate the container between two unrelated (i.e. no network storage)
hosts.
I've discovered at least one other problem with my cheesy rsync
method, although it's not clear to me whether or not it is a bug in my
understanding again or an actual bug. I will post some details about
this soon.
> Having said that, I planned to build one more tool on top of CRIU, that
> does live migration, takes care of memory pre-dumps, filesystems and
> so on.
>
> The existing state of p.haul is not even close to be final. It's just
> a demonstration how live migration could look like.
Cool! I expect that we'll be interested in using/contributing to this
at some point.
Tycho
> > [1]: https://github.com/lxc/lxc/commit/735f2c6e504a541cbb2592a3f94858bf337a24ff
> >
> > Tycho
> >
> >>
> >>> I'm expecting
> >>> criu to restore from there (including mounting udev, which is
> >>> presumably why /dev/null is missing). I guess mounting udev would also
> >>> fix this problem, though? I'm not sure.
> >>>
> >>> Tycho
> >>>
> >>>>> --Saied
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Thu, Aug 28, 2014 at 8:27 AM, Tycho Andersen <tycho.andersen at canonical.com <mailto:tycho.andersen at canonical.com>> wrote:
> >>>>>
> >>>>> If the target of a bind mount doesn't exist, create it. In particular, this
> >>>>> happens with /dev/ptmx across hosts under LXC. We could also mkdir -p any path
> >>>>> to the target, although I'm not sure if that is a case that occurrs in the
> >>>>> wild.
> >>>>>
> >>>>> Signed-off-by: Tycho Andersen <tycho.andersen at canonical.com <mailto:tycho.andersen at canonical.com>>
> >>>>> ---
> >>>>> mount.c | 18 ++++++++++++++++++
> >>>>> 1 file changed, 18 insertions(+)
> >>>>>
> >>>>> diff --git a/mount.c b/mount.c
> >>>>> index 9bb8a17..2108907 100644
> >>>>> --- a/mount.c
> >>>>> +++ b/mount.c
> >>>>> @@ -1346,6 +1346,24 @@ static int do_bind_mount(struct mount_info *mi)
> >>>>> root = rpath;
> >>>>> do_bind:
> >>>>> pr_info("\tBind %s to %s\n", root, mi->mountpoint);
> >>>>> +
> >>>>> + if (access(mi->mountpoint, F_OK)) {
> >>>>> + if (errno == ENOENT) {
> >>>>> + FILE *f;
> >>>>> +
> >>>>> + f = fopen(mi->mountpoint, "w");
> >>>>> + if (!f) {
> >>>>> + pr_perror("couldn't write 0 length %s", mi->mountpoint);
> >>>>> + return -1;
> >>>>> + }
> >>>>> +
> >>>>> + fclose(f);
> >>>>> + } else {
> >>>>> + pr_perror("Couldn't access %s", mi->mountpoint);
> >>>>> + return -1;
> >>>>> + }
> >>>>> + }
> >>>>> +
> >>>>> if (mount(root, mi->mountpoint, NULL,
> >>>>> MS_BIND, NULL) < 0) {
> >>>>> pr_perror("Can't mount at %s", mi->mountpoint);
> >>>>> --
> >>>>> 1.9.1
> >>>>>
> >>>>> _______________________________________________
> >>>>> CRIU mailing list
> >>>>> CRIU at openvz.org <mailto:CRIU at openvz.org>
> >>>>> https://lists.openvz.org/mailman/listinfo/criu
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> CRIU mailing list
> >>>>> CRIU at openvz.org
> >>>>> https://lists.openvz.org/mailman/listinfo/criu
> >>>>>
> >>>>
> >>> .
> >>>
> >>
> > .
> >
>
More information about the CRIU
mailing list