Ksplice: kernel patches without reboots

Ksplice: kernel patches without reboots

Posted May 1, 2008 0:22 UTC (Thu) by gdt (subscriber, #6284)
In reply to: Ksplice: kernel patches without reboots by dlang
Parent article: Ksplice: kernel patches without reboots

any system like this should be isolated anyway

In practice that's increasingly difficult. Datasets are growing so large that the last thing you want is two copies of them, so you end up with the input data being remotely hosted and pulled across the Internet on demand. It's this sort of use that the academic community created the Internet for.

The other problem with scientific computing is simply that I might not want to reboot the system at this moment. Imagine that I've concurrently booked four radiotelescopes, which is about a six-month wait. I've got them streaming into my processing cluster. A security patch arrives. If I apply the patch and reboot then I lose resolution, and thus my experiment may be inconclusive. If I don't apply the patch and the machine is subverted then there are data integrity issues and again the experiment is inconclusive. In both cases I wait another six months and try again. My favoured choice would be to apply the patch whilst still running the telescope correlation.

I'm not saying the ksplice is the best thing since sliced bread. But it does have some use, particularly outside of the typical server application that Linux is generally used for.

---

(Log in to post comments)

if you don't have more then one copy of your data you run the serious risk of loosing it. 

even for huge datasets, it's cheaper to keep an extra copy then to recreate the data.

I'm not saying that ksplice is worthless, I'm disagreeing with the idea that was posted that
it's required for these situations.

Yeah, but using an extra copy for failover requires that it be online 
*now*. Using an extra copy for redundancy only does not require that (and 
is much cheaper: how will you keep an extra online copy of the ATLAS 
detector's collected data? It's far too large to keep even *one* copy at 
any one site: keeping an extra online copy means doubling the size of an 
already large collaboration...)

Do you know how much data Google keeps. And they keep three copies not too. And in
Geographically separated locations. So the solution is essentially to make multiple copies.
Actually as Google has shown even two copies are not enough.

But the point about academic workloads is that often we use every desktop in the department as
a distributed supercomputer, so the nodes are both exposed to every possible attack because
people want their desktops accessible from outside (at least via ssh) and want to be able to
surf the web, and may be running background jobs for weeks at a time belonging to other people
who don't want them to be restarted. The conflict between these two factors is where this kind
of technology becomes important.

if you are running on random desktops that are used for other things, your software had better
be able to handle reboots/crashes/power outages anyway as those events will happen.

while I see some use for live patching, I really don't see where it becomes a killer feature