Hello Pete, Thank you very much for your contribution. I've repeatedly asked Sergey how to reproduce and the details, but got no good answers. I hope your contribution will make the details clearer. Hans-Peter Jansen: > 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. I'd ask generic questions (to anyone). - Is such handling done in the container, or in the generic linux checkpoint/restart? - If it is done in the generic feature, then is the linux checkpoint/restart feature specific to the containers? - If not, we will be able to reproduce without any containers, no openvz, no old kernel. As a first step, I need to know the detail steps to reproduce the problem since I don't know much about suspend/resume. > 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. It depends upon how CT finds the opend files. I have another idea. - add a notifier-chain into the suspend feature (if there is not currently). - any module who opens a file internaly regists itself to the notifier-chain. - when the suspend event is notified via the notifier-chain, the module handle it. J. R. Okajima -- 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
