On 6/28/07, Steve Devine <[EMAIL PROTECTED]> wrote:
Steven Jenkins wrote: > > > On 6/28/07, *Steve Devine* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > wrote: > > We have switched some of our servers over to binaries compiled > with fast > restart. > > > > Others may disagree, but my opinion is that Fast Restart is not yet > ready for production use. Testing is always helpful, though. Man I'm sorry to hear that .. we used this because we wanted to shorten the down time for bringing a server back on line when it has 1.2 possible disk space. That a long salvage window but maybe it would have been worth it.
I was talking about something else not being ready for production, not Fast Restart (which is fine for production). My apologies. Fast Restart can shorten your startup times, but it leaves the System Administrator to do the salvaging. Were I to use Fast Restart, I would - parse the output of FileLog after startup (or vos listvol vs vos listvldb output) to get a list of volumes to salvage manually, - possibly prioritize those (eg, bring RW's online first, not RO's that have good copies elsewhere, etc) - manually salvage them I'd have that in a script to be run after a restart. The benefit of Fast Restart is that even if you have a lot of volumes that need to be salvaged, the fileserver can be serving other volumes while you manually salvage the rest. Keep in mind that you'll have to salvage those one at a time or bos will shut the fileserver down. If you have to salvage a lot of volumes, Fast Restart will actually slow down your recovery time, so you'll want to consider that trade-off. (ie, you can't salvage in parallel while the fileserver is running) Steven
