Re: howto debug a complete hard reset

On Sat Apr 14 12, Jeremie Le Hen wrote:
> On Sat, Apr 14, 2012 at 08:59:42AM -0400, Robert Huff wrote:
> > 
> > >  This is probably a sysctl handler that is causing the reboot.  You can
> > >  run this one-liner to spot the culprit (use sh):
> > >  
> > >      for i in $(sysctl -Na); do sysctl $i >> ~/sysctl.out; sync; done
> > >  
> > >  Each sysctl will be called in turn and the output is appended to
> > >  a file, but the file will forcibly written to the disk before the
> > >  next occurence.
> > 
> > 	Um ... it is my understanding sync(8) does not guarantee
> > pending i/o will be written before it returns, but merely requests
> > this happen irrespective of when it would normally occur.
> > 	An I mistaken?
> 
> Honestly I don't know, but I have do admit that the small paragraph in
> the BUGS section of the sync(2) manpage is a little bit shivering:
> 
>     BUGS
> 	 The sync() system call may return before the buffers are completely
> 	 flushed.
> 
> 
> Can any enlightened person answer this?

sync(2) does REQUEST an immediate write to disk. however for this to actually
be the case, one has to disable softupdates and disable the write cache of that
particular disk. the write cache of hdds is enabled by default, because
disabling it will give you a huge performance drop. there's a small section
about this in tuning(7).

cheers.
alex

ps: SU+J also mustn't be enabled for immediate writes to happen.

> 
> -- 
> Jeremie Le Hen
> 
> Men are born free and equal.  Later on, they're on their own.
> 				Jean Yanne
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"