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 YanneReceived on Sat Apr 14 2012 - 16:11:35 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:25 UTC