[CRIU] [RFC PATCH 0/6] introduce FSTYPE__AUTO
Oleg Nesterov
oleg at redhat.com
Sat Mar 28 08:23:28 PDT 2015
On 03/27, Oleg Nesterov wrote:
>
> Hello.
>
> Not for inclusion. RFC, just for discussion, etc.
>
> I tried to dump/restore the dummy (/bin/sleep actually) application
> running in unshared mnt namespace. Dump/Restore fails because a lot
> of filesystems are FSTYPE__UNSUPPORTED: xfs, hugetlbfs, autofs, configfs,
> selinuxfs.
>
> OK, lets forget about xfs for the moment. But hugetlbfs? configfs ??
> They do not need anything special. Just do_new_mount() needs to know
> fsname to restore this mount correctly.
>
> Of course, trivial to fix. Just add FSTYPE__HUGETLBFS/etc. But isn't
> this ugly?
>
> AND. More importantly. IMO, we want the command line option to support
> the filesystems which can "just work". This is impossible with the
> compiled-in fstypes[].
>
> Please review.
In case it was not clear, I didn't even meant the patches in the first
place. The main question is: do you agree this feature makes sense?
> Again, this is not for inclusion. 3/6 should be reimplemented (see the
> changelog) and we need to populate the FSTYPE__AUTO entries earlier on
> restore. Even for correctness. parse_mountinfo_ent() is called at the
> start of restore afaics. But seems to work even if not 100% correct.
And we do not even need the changes in protobuf/mnt.proto. We only need
to dump/restore the additional string (list of used FSTYPE__AUTO names).
Can we (ab)use inventory_entry and inventory.img for that?
Oleg.
More information about the CRIU
mailing list