[Ksummit-2012-discuss] [ATTEND] General container technology
jeff.liu at oracle.com
Thu Jun 21 13:14:38 UTC 2012
I'd like to seek an opportunity to attend this year's KS, especially interesting to get involved in the general
container technology discussion that Glauber has proposed.
I am a new comer in kernel upstream, I started playing with kernel after transfer to Oracle kernel team around Sep，2011,
and then got started to study the kernel container's technology, as well as maintains the LXC tools on our Enterprise Linux release.
Ashamed to say, I have only done some trivial patches in the past 10 months, includes introduce SEEK_DATA/SEEK_HOLE to XFS/EXT4, the former
has been merged, but the latter was still pending due to some dependent things, and fix a few bugs for Btrfs/XFS.
Recently, I have tried to implement the container disk quota feature, and got some positive feedbacks in V2 patch set.
The V3 patch set is still in development stage.
Before posting V3 to the list, I'd like to improve the VFS quota scalability firstly. IMHO, the container quota could also get potential
performance benefits from that. Now the idea is to move those global locks as well as the global dquot hash list to individual super block.
There is no code change requirement from the file system's(which are bound to VFS quota) perspective except OCFS2, it need a bits fix up accordingly since
it use the exported dq_data_lock from dquot.
Now the initial patch is basically done, however, I still waiting for a powerful server with multiple cores to
measure the lock contentions.
Besides above, I'd like to discuss some corner things regarding general containers.
There are a couple of proc files are still be global effective IMHO, especially from the LXC guest's point of view, like:
* Fork bomb, make sense?
AFAICS, there is no isolation for iptables and NFS for now.
Add a new iptable rule insides the container guest, it will presented on the outsides list, and vice versa.
NFS has same issue too, any modification to container guest's /etc/exports could be observed from the outsides, and
showmount(8) even does not work, it just hang instead :( Am not sure supply NFS support at container is reasonable or not.
Previously, we only run sanity check for container on our Linux release, as the main features are supplied in kernel, we hope to automate
those related subsystem tests as as far as possible. If there already have such tools in the community, I'd like to take part it.
* Wiki page for container?
Is is make sense to set up a wiki page for container development collaboration?
Maybe it would be helpful if we have a wiki page with the features update, new ideas, as well the status of the ongoing tasks.
Last but not least, I know it's pretty difficult to get an approval from the KS committees as a junior. What I can do is to continue to make more
contributions, and screwed up my courage to send this email out. ^_^
More information about the Ksummit-2012-discuss