On Mon, Nov 15, 2010 at 03:52:05PM +0100, Bernd Schubert wrote: > On Friday, November 12, 2010, Lars Ellenberg wrote: > > On Fri, Nov 12, 2010 at 05:04:43PM +0100, [email protected] wrote: > > > # HG changeset patch > > > # User Bernd Schubert <[email protected]> > > > # Date 1289577717 -3600 > > > # Node ID 750c5a016d8135a7170d4a2fbe0de0f98478c572 > > > # Parent 0324966049c1e90b9d18c9c63041d2c73964d42f > > > cl_log: Restore old logfile open/seek/write/close behaviour. > > > > > > This patch actually does not completely revert commit 2435:ada347da564d, > > > but adds a layer to support both, open/write/close and and > > > open-once, write, close/open-for signal handlers > > > > > > It also changes a marco into a static function. And also uses > > > system IO (open/close/write) instead of libc IO (fopen/fclose/fwrite). > > > Libc IO has a buffer, which is not suitable for log files (in case of > > > a stonith, all the buffer and which might large, will be missing in > > > log files. > > > > You are aware of this thread? > > http://www.mail-archive.com/[email protected]/msg05590.html > > No, sorry I did not notice that one. > > > > > Basically I suggest to fflush every time the inner message logging loop > > is done, and add an fsync for pri ERR and worse. > > we can make that warning and worse, or even make it configurable. > > > > It should perform better than the always unbuffered approach, while > > keeping similar guarantees about not losing (important) messages. > > I think it is a good idea to flush the kernel buffer, but do we really want > to > have a libc buffer? There is no way to flush the libc buffer from kernel > space, e.g. with sysrq. The problem is that a remote system might stonith > that > system for whatever reason and it would be good to have the latest logs then.
My approach was: a) fflush makes glibc buffer flush to kernel page cache. fflush is done whenever the current message backlog was processed. it will "do itself" if the message backlog is so huge that the glibc buffers (usually in the order of 8k, iirc) fill up anyways. We could of course add in an other explicit fflush every so often, or for every ERROR or worse (or warning or worse). It will usually still perform better, as we do the write() syscall only for full glibc buffers. b) fsync will (ok: should) make kernel page cache go to stable storage. fsync is done whenever the current message backlog was processed, if at least one ERROR or worse was counted. Again we can (and probably should) add an extra fsync every X messages in case the message backlog is huge, but only for severe messages. > I noticed that even IPMI resets nowadays use acpi to trigger a reboot, I have > not checked the kernel code yet, but in principal that allows the kernel to > do > an emergy flush of its buffers, but no way to do that for libc... > > > > > Also, if you want to comment on the issues raised in > > http://www.mail-archive.com/[email protected]/msg05598.html > > about log rotation and files potentially being in use anyways, still? > > Anything not yet answered by those patches here? As long as we still do the open(); write(); close(); unless the library client explicitly enables SIGHUP handling, and the log rotate does not immediately gzip the stuff, we are good. If you think it buys performance, we could weaken it still to (pseudo code) stat(&persistent) open stat(&tmp) if (tmp != persistent) close open write > Hmm, well, we need to add the the kill action to the logrotate scripts, > but those scripts are in the heartbeat package. > Maybe not that optimal that heartbeat (without enabled logd) and > ha-logd use the very same log files by default. Should we change the internal defaults of logd, or just provide an "example logd.cf" with different settings? -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
