Ask Slashdot: Faster Reboots? 28
RobertPearse
submits this question: Here's an article about
ILM engineers using a small
Linux box to reboot systems quickly. They mention a "TTL
data-acquisition card". Housed in a linux box, it allows
them to reboot a system very quickly. Anybody know
anything about this? My company is a Microsoft shop -- and
given the fragility of NT, this sounds like a great idea.
(God forbid we need to reboot an NT box ;-)"
Re:I read it differently (Score:1)
Re:Take a tip from laptops (Score:3)
These sort of protection schemes are really only good at protecting you from hardware failures, which is not what you are looking for. Also, if your system has a lot of memory it can take quite a while to dump the memory to disk and read it off again on boot. I work on machines that routinely have 4GB of memory, and when they crash (and core dump) it can easily take 15-30 minutes to finish dumping the core. These machines can boot regularly in less than 10 minutes (easily). Of course with the checkpointing scheme you don't lose as much work, which is a big thing when you are using the machine to do an extremely computationally intensive task or have a huge database in memory.
Re:Take a tip from laptops (Score:1)
In other words, it's not a problem.
My laptop is faster at loading the 64M (+ 4M video RAM) image off disk than it is at booting up to Linux + X. Add in the extra time it takes me to start the applications and a regular boot becomes even slower. Which is why I always use the suspend-to-disk option of my laptop.
The worst possible way (Score:2)
Given that the standard ext2 filesystem forces an fsck every 16 mounts, I was having to sit through long, slow, irritating fscks about once every week or two. So I used ext2ed to change the forced fsck to every 64 mounts instead.
This is not recommended because you have a greater chance of losing data. But, it makes those fscks happen alot less frequently!
Take a tip from laptops (Score:3)
For faster reboots, all you have to do is reboot, let the system come up, and then save the state of the system at this point. Later when NT goes BSOD, you just reload your freshly rebooted image which is much faster than a true reboot, since the time it takes to restore a system state is essentially the time it takes to reload RAM (128MB tops) plus state info (insignificantly sized chunk of data).
Re:Take a tip from laptops (Score:1)
remote reboot for NT??? (Score:1)
This sounds like some of the products that I cam across in the back of some IT/Network magazine the other day. In about 10 pages of ads, there were at least four 1/4 page ads for products that would let an admin remotely reboot machines. I guess with the spread of NT into corporations, I guess devices like this are becoming a necessity. Although, from Rob's post today, it sounds like until he gets the hardware drivers ironed out, Slashdot might need one.
Re:Clever block ordering for fast reboots? (Score:1)
I remember reading about that feature of win98 in some PC magazine. When the authors of the article tried it out, it saved something like 2 seconds off the 10 second load time for Word, but to do so it took about 2-3 hours for the optimizer to reorder the hard drive.
MR. BIOS (Score:1)
A joke (Score:1)
Re:Take a tip from laptops (Score:2)
On every laptop I've ever had, once you have 64-128MB of memory, the RAM reload process is much slower than an actual boot.
On big x86 servers (especially EISA machines like Compaqs), the BIOS POST time is almost as long or longer than the actual operating system boot.
--
under 10 sec possible (Score:3)
Most importantly, the runlevel stuff (SysV initialization) is just abysmally slow. If you want fast reboots, put just what you need into /etc/rc and get rid of all the other stuff.
It also helps to make a custom kernel that includes only the modules and drivers you need.
If you have certain kinds of hardware or controllers in your system (Adaptec comes to mind), trying to achieve fast reboots is hopeless because they need lengthy initialization routines and microcote downloads.
This kind of setup isn't good for many day-to-day uses, and it will probably cause problems with distributions like RedHat or Caldera. But if you want fast reboots, you can get them. Last I did this was on an older distribution of Slackware.
Fast Reboots (Score:2)
The key to fast reboots is to do the "Rapid Resume" type of stuff that IBM PCs used to loadly boast as a feature several years ago. Basicly, on demand, it would write the contents of memeory to a special place on the Hard Drive. Whenever it boots up and goes through POST, it looks to that area, reads in the data to memory, and resumes at the exact spot it was before shutdown, almost instantly.
There's no reason this type of technology couldn't be used in other other way. I would guess that in this case it uses of a card with flashable memory, and saving state where it is right after a boot or right before doing a process that could crash a system...
Re:Clever block ordering for fast reboots? (Score:1)
I read it differently (Score:1)
-earl
I'd done something similar before. (Score:2)
TTL i/o card (Score:1)
-Chris
Re:TTL i/o card (Score:1)
Aww, but Uncle Owen, I wanted more than 12 outputs! I've got a traffic light and a toaster I want to connect to the Internet for novelty's sake.
-Chris
Re:Fast Reboots (Score:1)
Re:I read it differently (Score:1)
Re:TTL i/o card (Score:1)
TTL I/O Cards (Score:2)
I don't see anyone stating the obvious (Score:1)
Re:The worst possible way (Score:1)
read-only by default, then manually remount
it read/write when you need to install or
upgrade stuff. AFAIK read-only mounts don't
count toward the maximal mount count for fsck.
Re:remote reboot for slashdot (Score:2)
Use with care
I love it!
the AntiCypher