[CRIU] [RFC PATCH 3/6] introduce mnt_entry->fsname for FSTYPE__AUTO filesystems

[Oleg Nesterov]

On 03/30, Pavel Emelyanov wrote:
>
> On 03/27/2015 08:55 PM, Oleg Nesterov wrote:
> > A separate change for documentation purposes.
> >
> > This patch adds mnt_entry->fsname to dump/restore the ->fsname of the
> > FSTYPE__AUTO filesystems. This is ugly, we need to dump and restore
> > the list of FSTYPE__AUTO names once,
>
> I don't understand this :( What's wrong with how it's done in this patch?

Well, I do not like the new mnt_entry->fsname field. In fact I do not
want to touch this mnt.proto at all. We can avoid this afaics, see below.

This is suboptimal although we do not really care.

More importantly, this doesn't look clean. Perhaps even wrong in the long
term.

prepare_mnt_ns() calls collect_mntinfo() before collect_mnt_from_image(),
and collect_mntinfo() does parse_mountinfo() too. So unless the user passes
the same --xxx argument to restore (and I think this arg should be nacked
if "restore"), find_fstype_by_name() will return FSTYPE__UNSUPPORTED while
this fs was dumped as FSTYPE__AUTO.

Probably (but I am not really sure) this doesn't matter today correctness
wise, but this doesn't look good anyway.

So. Can't we just dump/restore an additional string?

To simplify the discussion, lets suppose that we want to dump/restore that
--xxx argument (we do not actually want this).

How can we do this?

Can I add .xxx to "struct inventory_entry" ? check_img_inventory() is called
early, and this is what we need on restore.

But unfortunately write_img_inventory() is called early too, and this doesn't
allow to dump the list of actually used FSTYPE__AUTO names after dump_namespaces.

Can I move write_img_inventory() down to make it the last "dump"? Or is there
a better solution?

Oleg.