Ingo Molnar <mingo@xxxxxxx> writes: > * Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > >> >> 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 from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html