Re: aufs as root vor openvz CT

[Hans-Peter Jansen <hpj@urpla.net>]

Dear Junjiro, dear Sergey,

first of all, I just try to transform the communication between you two in 
order to help both parties. I'm not affiliated in any of the two, its just a 
poor mans AUFS contribution.

On Montag, 21. Juli 2014 15:33:15 Sergey Korshunoff wrote:
> > I won't be helpful for you until you give me enough information.
> > Do you have any special reason not to give the information?
> 
> I'm trying to use a aufs as a root fs for container. I use openvz
> kernels 2.6.18 and 2.6.32. While container starts, stops and works
> well it can not be suspended. There is nothing special to a kernel
> version and even union fs type (aufs, uniionfs). Problem is common to
> any stacked fs which opens fd itself. This is why I do not try to
> give info asked in README
> 
> Suspend count currently a fd opened by a stacked fs (internal fd) as a
> fd opened by application in container. I'm trying to ask openvz
> developers (https://bugzilla.openvz.org/show_bug.cgi?id=3024) about a
> method allowing to exclude internal fd of stacked fs from a suspend
> set.
> 
> Suspend perform a closing of the opened fd's. This fd's are reopened
> while resume is performed. Internal fd's of the stacked fs must not be
> counted by this processes.

Junjiro, openvz is a container technology (CT) similar to docker. I can 
imagine, that these technologies have a problem, that describes as follows:

In order to perform a proper suspend/resume cycle, the CT has to arrange 
everything to the state before the suspend. Therefore, they track the opened 
files, and restore their state during resume. Layering FS (LFS) do cause 
problems in this scenario, since files opened by them don't belong to any 
application running in the container.

As it stands, a LFS can't do much to solve the problem in itself, other then 
hinting the CT during suspend, which fd is used by the LFS itself. The CT 
should simply ignore those on resume, given, that opening the fd and restoring 
its state in the application layer should restore the LFS arrangement 
implicitly.

Since this issue is generic to LFS using their own fds, I'm sending this to 
the new linux-unionfs ML, too, and suggest to discuss it any further over 
there.

So, either define a special open flag for LFS internal fds, which, I guess, is 
rather unpopular, or define a respective fcntl, that those LFS should 
implement. Otherwise, every CT needs to detect the internal fds of every LFS 
implementation heuristically, which is the worst solution, of course.

Pete