[CRIU] [RFC PATCH 0/6] introduce FSTYPE__AUTO

[Pavel Emelyanov]

On 03/27/2015 08:55 PM, 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.

XFS is unsupported just because nobody marked it as supported :)

Hugetlbfs has something on-board, need to check what it is and
how it should be C/R-ed.

AutoFS is a terrible beast :( We can't "just" dump and restore it
as it _may_ have connection to the daemon that we're C/R-ing. So
this one _does_ need special care when C/R-ed.

ConfigFS is, well, not expected to be seen inside container, so we
didn't add one in supported list, but can. No problems AFAIK.

As far as selinuxfs is concerned, maybe it can be just added too,
I just do not know.

> 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?

Well, we did this list deliberately to avoid accidents with filesystems
that need special caring. Like autofs. Like NFS. Like fuse :)

> 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.

I really like the feature and have only a couple of comments to the 
patchset itself, please see them in respective patches.

> 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.
> 
> Oleg.

-- Pavel