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 -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
