Oren Laadan [off-list ref] writes:
Dave Hansen wrote:
quoted
On Fri, 2009-03-13 at 14:01 -0700, Linus Torvalds wrote:
quoted
On Fri, 13 Mar 2009, Alexey Dobriyan wrote:
quoted
quoted
Let's face it, we're not going to _ever_ checkpoint any kind of general
case process. Just TCP makes that fundamentally impossible in the general
case, and there are lots and lots of other cases too (just something as
totally _trivial_ as all the files in the filesystem that don't get rolled
back).
What do you mean here? Unlinked files?
Or modified files, or anything else. "External state" is a pretty damn
wide net. It's not just TCP sequence numbers and another machine.
This is precisely the reason that we've focused so hard on containers,
and *didn't* just jump right into checkpoint/restart; we're trying
really hard to constrain the _truly_ external things that a process can
interact with.
The approach so far has largely been to make things are external to a
process at least *internal* to a container. Network, pid, ipc, and uts
namespaces, for example. An ipc/sem.c semaphore may be external to a
process, so we'll just pick the whole namespace up and checkpoint it
along with the process.
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.
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>
* Eric W. Biederman [off-list ref] wrote:
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.]
Ingo
--
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>
On Sat, 2009-03-14 at 01:12 -0700, Ingo Molnar wrote:
* 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.]
From an ordinary user perspective, I hate loosing my desktop state every
time there is a power bump or a new kernel/video driver comes down from
the distro provider. Some of the stuff I loose:
*All my terminals
*many tabs and windows
*each in a different directory
*vi
*which files I was editing
*which function I was coding
*screen
*scrollback buffer's contents
*history for debugging code
*command line arguments
*State of running apps
*web browser
*Tabs, yes it saves urls on crash, but sometimes the page cant
come back up (say, because of a form)
*where the windows are on the desktop
*evolution
*what folder is selected
*which message within the folder is selected
*rhythmbox
*misc other apps
Being able to reboot and get back to exactly where I was before the
reboot would save me a lot of time restarting apps and getting my
desktop back to where it was before the reboot. I'd also be more
inclined to reboot to get security updates more frequently if I didn't
loose track of what I was doing in the session, making machines more
secure in the process.
Kevin
PS: Yes, I know both GNOME and KDE have tried to deal with some of this
with their session manager stuff, but it doesn't restore everything and
only supported by some apps. It would probably take more work to get all
apps working with the session management stuff then supporting kernel
C/R.
Ingo
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
--
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>