Who will want rebootless upgrades?

Posted Jul 28, 2011 21:35 UTC (Thu) by cmccabe (guest, #60281)
In reply to: Who will want rebootless upgrades? by Cyberax
Parent article: Ksplice and CentOS

> Ah, but you don't need to keep RAM coherent after each operation.
> You need to do it only after network communication and/or disk IO.

It depends on how the application is written. And given that fsync still gets a blank stare from most application developers, I'm not optimistic.

Database-backed apps might have a little bit more of a chance, because database designers thought about these issues. But most database replication is still semi-synchronous rather than synchronous, because people don't want to pay the speed cost. There are also clustered databases and database engines, but they are the exception rather than the rule.

Who will want rebootless upgrades?

Posted Jul 28, 2011 22:17 UTC (Thu) by dlang (guest, #313) [Link] (2 responses)

one word:

mmap

Who will want rebootless upgrades?

Posted Aug 3, 2011 23:15 UTC (Wed) by cmccabe (guest, #60281) [Link] (1 responses)

mmap is great, but without calling msync from time to time, you have no guarantee that the data in memory matches what is on the disk. If you crash before the kernel chooses to write those pages back to disk, that work is gone.

Who will want rebootless upgrades?

Posted Aug 5, 2011 22:07 UTC (Fri) by dlang (guest, #313) [Link]

my point is that if you use mmap you don't know when a write to disk takes place. it could be well before you call msync

Who will want rebootless upgrades?

Posted Jul 29, 2011 17:38 UTC (Fri) by giraffedata (guest, #1954) [Link] (1 responses)

Ah, but you don't need to keep RAM coherent after each operation. You need to do it only after network communication and/or disk IO.
It depends on how the application is written.

I don't see how. The principle seems sound; how would you write an application that won't fail over properly without multiple synchronizations of memory between I/Os?

The only thing I can think of is something where time itself is part of the function -- e.g. if a query has to be answered within 30 seconds and the primary has been working on it for 25 seconds before he dies, the backup won't be able to respond within 30 seconds of the query unless he knows what the primary computed between the query and the failure.

Who will want rebootless upgrades?

Posted Jul 29, 2011 19:27 UTC (Fri) by raven667 (subscriber, #5198) [Link]

The secondary host is calculating the result at the same time as the primary using the same data. Maybe this demonstration will help make more sense.

http://www.youtube.com/watch?v=NCMMwGC0hD8

Fast forward to the 4-5m mark if you want to skip the explanation.