> 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