buffering history text file writes

[Ilya Etingof]

> fflush() != disk write. The data go to VM cache and become
> visiable for other processes.

Certainly, yes.

The point is that if history write stream as assigned a buffer which is
large enough to remain unflushed during a few update daemon runs, there
might be some savings. Particularly:

1. Judging from the default for update daemon to store filesystem
   metadata (normally, 5 secs), inode information of history text file
   would get stored on disk less often.

   This seems to work in the similar way as putting history file on a 
   'noatime' mounted filesystem.

2. New history lines would get written on disk less often (usual default
   for update daemon is 30 secs for dirty buffers).

3. Seldom fflush() might result in less frequency of write() system call.

> Can you run innd with and without this hack (and without any others
> hardware/software chages) during 1+ hour and send average hiswrite time ?

Yes, here're the results for about one hour run.

Before the hack:

Code region      Time           Pct    Invoked  Min(ms)   Avg(ms)   Max(ms)
history write    00:00:11.041   0.3%   39273    0.075     0.281     0.696               

After the hack:

Code region      Time           Pct    Invoked  Min(ms)   Avg(ms)   Max(ms)
history write    00:00:05.374   0.1%   54771    0.014     0.098     0.220

This is collected with 64K buffer set to history file write stream.

As far as I understand it, the INN timer might notice only the third
saving of the above three as actual disk writes seem to be asynchronous
to innd process.

-ilya