On Jan 17, 2008 11:43 AM, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote: > [Olaf van der Spek] > > But you do agree the sync could introduce a delay? > > Its purpose is to make sure most state saving IO is done before > killing daemons that do not need to save state, so sure, it _could_ > introduce a delay. I do not believe it introduces a significant delay > in the shutdown itself, but am interested in numbers showing > otherwise. The delay would either be in sendsigs, or when the file > systems themselves are umounted, if there is a large amount of buffers > to flush.
But sendsigs uses mostly CPU time, so it'd be nice to interleave that with IO time. I don't have any numbers, I'm just reasoning based on theory. Do you have any numbers on how long the sync call takes? > > In that case you could increase the 10 seconds to 15 and do the sync > > at 5 seconds. That way, those daemons do still get 10 seconds after > > sync to cleanly terminate, but you do get the advantage of disk IO > > and terminating daemons in parallel. > > Well, the point of the sync is to make it more predictable how much > resources are available during the 10 seconds sendsigs give the > daemons to terminate. Adding a sync and increasing the period would > make it less predictable, not more predictable. Thus, I believe it is > a bad idea. Don't the daemons still get the same 10 seconds after the sync? So you still have 10 seconds with low IO. > If you can demonstrate that the sync changes the shutdown time > significantly, I am willing to discuss a change, but as the kernel > buffers need to be flushed some time during shutdown, and the daemons > killed by sendsigs in the normal case should die quickly (on my test > machine, within the first second), I doubt the difference is huge. It may not be huge, but I assume any reduction in time is nice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
