4 ms·

You linked to the migration of a single operating system kernel. That is very different from reproducing the running state of an entire distributed system. Migr

by scott_s 10y ago

You linked to the migration of a single operating system kernel. That is very different from reproducing the running state of an entire distributed system. Migrating a single kernel is not easy, but straight-forward: you have access to all of the relevant pieces (in memory process state, and state on disks) in one place. With a distributed system, that is not so, since the the running state of a distributed system will include information in-flight, some of which is not virtualized. It is possible to migrate the state of a distributed system by designing a protocol such that all of the components stop sending information around, so that you can be sure you did not miss anything. But I think that violates the spirit of the phrase "running state", since you essentially stopped the system. It's also not necessarily so that post-migration, the system will act the same.

deegles 10y ago
So, basically the same reasons why I'd never step into a teleporter :)
yarou 10y ago
Why would you need to copy the entire running state of the distributed system?
teraflop 10y ago
You might be interested in the Chandy-Lamport snapshot algorithm, which can do what you describe without stopping the system's execution.
- scott_s 10y ago
  I'm aware of such things, and in fact I work on a system that supports something very similar. (Paper to be published by my colleagues in the industry track of VLDB.) But that is a logical snapshot. Through a clever protocol, and assuming some characteristics of your transport, you can save a state across your system that is logically consistent. That is, if you restored to this logical state, the distributed application can resume from that point, and maintain integrity. You may, however, lose information from your system that was computed after you took your snapshot. The state is logically consistent, but unlikely to be representative of any actual point in time.
  - teraflop 10y ago
    Strictly speaking you're correct -- a distributed snapshot doesn't capture the state of the system at a single instant. But there's a sense in which the nondeterminism introduced by the snapshot is no worse than the nondeterminism that is intrinsic to a distributed system. To be more precise: any "possible outcome" of the snapshot was also possible at some point during the original execution. And likewise, any "impossible outcome" of the snapshot was also ruled out at some point in the original. So if viewed from the outside, the fact that you took and restored a snapshot is indistinguishable from the normal situation of having an asynchronous network. It can't cause the system to exhibit any behaviors that weren't otherwise allowable. (Apologies if I'm just restating what you already know; other readers may not be aware of it. This might be the same property that you're calling "integrity".) This is reminiscent of one of Scott Aaronson's comments from the original article. If quantum effects are significant in the brain, then it's impossible -- even in principle -- to "perfectly" copy it such that the original and the copy are guaranteed to behave identically. But if the original and the copy are statistically indistinguishable, it amounts to the same thing.

by scott_s 10y ago

deegles 10y ago

So, basically the same reasons why I'd never step into a teleporter :)

yarou 10y ago

Why would you need to copy the entire running state of the distributed system?

teraflop 10y ago

You might be interested in the Chandy-Lamport snapshot algorithm, which can do what you describe without stopping the system's execution.

scott_s 10y ago
I'm aware of such things, and in fact I work on a system that supports something very similar. (Paper to be published by my colleagues in the industry track of VLDB.) But that is a logical snapshot. Through a clever protocol, and assuming some characteristics of your transport, you can save a state across your system that is logically consistent. That is, if you restored to this logical state, the distributed application can resume from that point, and maintain integrity. You may, however, lose information from your system that was computed after you took your snapshot. The state is logically consistent, but unlikely to be representative of any actual point in time.
- teraflop 10y ago
  Strictly speaking you're correct -- a distributed snapshot doesn't capture the state of the system at a single instant. But there's a sense in which the nondeterminism introduced by the snapshot is no worse than the nondeterminism that is intrinsic to a distributed system. To be more precise: any "possible outcome" of the snapshot was also possible at some point during the original execution. And likewise, any "impossible outcome" of the snapshot was also ruled out at some point in the original. So if viewed from the outside, the fact that you took and restored a snapshot is indistinguishable from the normal situation of having an asynchronous network. It can't cause the system to exhibit any behaviors that weren't otherwise allowable. (Apologies if I'm just restating what you already know; other readers may not be aware of it. This might be the same property that you're calling "integrity".) This is reminiscent of one of Scott Aaronson's comments from the original article. If quantum effects are significant in the brain, then it's impossible -- even in principle -- to "perfectly" copy it such that the original and the copy are guaranteed to behave identically. But if the original and the copy are statistically indistinguishable, it amounts to the same thing.