Ingo Molnar [off-list ref] writes:

* Eric W. Biederman [off-list ref] wrote:

quoted

quoted

quoted

In the OpenVZ case, they've at least demonstrated that the 
filesystem can be moved largely with rsync.  Unlinked files 
need some in-kernel TLC (or /proc mangling) but it isn't 
*that* bad.

And in the Zap we have successfully used a log-based 
filesystem (specifically NILFS) to continuously snapshot the 
file-system atomically with taking a checkpoint, so it can 
easily branch off past checkpoints, including the file 
system.

And unlinked files can be (inefficiently) handled by saving 
their full contents with the checkpoint image - it's not a 
big toll on many apps (if you exclude Wine and UML...). At 
least that's a start.

Oren we might want to do a proof of concept implementation 
like I did with network namespaces.  That is done in the 
community and goes far enough to show we don't have horribly 
nasty code.  The patches and individual changes don't need to 
be quite perfect but close enough that they can be considered 
for merging.

For the network namespace that seems to have made a big 
difference.

I'm afraid in our clean start we may have focused a little too 
much on merging something simple and not gone far enough on 
showing that things will work.

After I had that in the network namespace and we had a clear 
vision of the direction.  We started merging the individual 
patches and things went well.

I'm curious: what is the actual end result other than good 
looking code? In terms of tangible benefits to the everyday 
Linux distro user. [This is not meant to be sarcastic, i'm
truly curious.]

Of the network namespace?  Sorry I'm not certain what you are asking.

Eric

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>