> That is interesting. So I guess the conclusion to this is, softupdates > is useful for bursty IO, but not sustained because it can get far behind > until it eventually reaches the point where the machine reboots silently. > I guess the delay until reboot is dependent on the size of max_softdeps. > If it is big, it takes a while. I mentioned this a while back in the context of suspended I/O (in this case, a RAID array busy dealing with a failed disk). There wasn't much interest in dealing with it evinced at that point. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
- softupdates and debug.max_softdeps Tom
- Re: softupdates and debug.max_softdeps Matthew Dillon
- Re: softupdates and debug.max_softdeps Tom
- Re: softupdates and debug.max_softdeps Peter Wemm
- Re: softupdates and debug.max_softdeps Tom
- Re: softupdates and debug.max_softde... Matthew Dillon
- Re: softupdates and debug.max_so... Tom
- Re: softupdates and debug.ma... Matthew Dillon
- Re: softupdates and debug.max_softde... Mike Smith
- Re: softupdates and debug.max_so... Mike Smith
- Re: softupdates and debug.max_so... Greg Lehey
- interesting results from sof... Matthew Dillon
- Re: interesting results from... Kirk McKusick
- Re: interesting results from... Tom
- Re: softupdates and debug.ma... Mike Smith
- Re: softupdates and debug.max_softdeps Keith Stevenson
- Re: softupdates and debug.max_softde... Matthew Dillon
- Re: softupdates and debug.max_so... Keith Stevenson
- Re: softupdates and debug.max_softdeps Matthew Dillon