Re: Fighting for the power. [syslogd]

Peter Jeremy wrote:
> On 2009-May-04 06:19:36 +0300, Alexander Motin <mav_at_freebsd.org> wrote:
>   
    ...snip...
>> number of idle disk write activity, but I haven't very succeeded. Even 
>> in my quite simple icewm X environment something was persistently 
>> writing something every several minutes. I have found and disabled some 
>> activity sources, but it was not enough.
>>     
>
> I've recently (in the last few days) worked through minimising the
> write activity on the SSD in my laptop (I wrote a tool that monitors
> write transfers via devstat(3) and it would be possible to track down
> the actual modified files via kqueue(2) if necessary).  I'm now down
> to about two chunks of about 13 transfers each per hour (due to entopy
> saving and ntp.drift updating).  The changes I made were:
> 1) Mount the SSD filesystems as noatime
> 2) Turn off all local syslogging (syslog is directed to another
>    system when my laptop is at home, lost otherwise).
>   

Regarding syslogd, I've considered adding support to batch/buffer writes 
to workaround a problem that I consider rather important: syslogd is not 
started early enough in the boot so it's not available to log msgs from 
other applications.  In particular I hit this because wpa_supplicant 
logs via syslog but when it's started at boot syslogd isn't available 
and since wpa_supplicant operates in a chroot'd environment it cannot 
defer connecting until syslogd has started up so nothing is ever 
logged.  I think we want syslogd to start very early and deal with the 
case where the local filesystem is not present.  My plan was to buffer 
msgs and then flush them at a later time.  But this might also be used 
to buffer log activity so local disk activity is staged (e.g. for the 
laptop or embedded use).

Maybe someone else has a better idea but I think we need to do something 
soon.

    Sam