Possible patch to cure CGI's not finding data for objects in status.dat

[Hiren Patel]

Cary Petterborg wrote:
> I have one question and one observation in addition to what I already 
> said....
> 
> Question:
> In the case of the web server and nagios being on the same system, how 
> much is an fsync() really going affect the performance of the system? 
> Can someone "quantify" the impact of a single fsync? (I guess that is 
> technically a second question.) If it were to do a sync() (where all the 
> open files are checked to ensure that they are sync'd) instead of an 
> fsync(), I would definitely agree - much bigger impact. But, the single 
> fsync at the end of writing a file should not be of any real 
> significance, except in the case where it means that the data is 
> actually there where it should be if it *is* done (e.g. my case).
> 
>  

I tried a program which I meant to attach to this mail that I deleted by 
mistake as I was composing this mail, that fopen'd a file, wrote a 
character at a time and either fclosed at the end, or fsync'd after each 
character, or sync'd after each character. it wrote 1MB worth of 
characters to the file.

this was the results on a ubuntu 9.04 dell m6300 laptop that was 
relatively idle at the time.

(no sync or fsync):
----
hirenp at firebird:/tmp$ time ./a.out

real	0m0.122s
user	0m0.108s
sys	0m0.008s
----

(no sync or fsync with a "dd if=/dev/random of=/tmp/test2 bs=1M 
count=100" running in another terminal)
----
hirenp at firebird:/tmp$ time ./a.out

real	0m0.052s
user	0m0.048s
sys	0m0.004s
----

(fsync)
----
hirenp at firebird:/tmp$ time ./a.out ; echo $?

real	0m2.422s
user	0m0.244s
sys	0m0.784s
0
----

(fsync with a dd "if=/dev/random of=/tmp/test2 bs=1M count=100" running 
in another terminal)
----
hirenp at firebird:/tmp$ time ./a.out ; echo $?

real	0m2.037s
user	0m0.248s
sys	0m0.872s
0
----

(sync - had to be interrupted, progress 5% on stop)
----
hirenp at firebird:/tmp$ time ./a.out
^C

real	8m15.111s
user	0m0.084s
sys	7m59.070s
----

(sync with a "if=/dev/random of=/tmp/test2 bs=1M count=100" running in 
another terminal - had to be interrupted, progress 5% on stop)
----
hirenp at firebird:/tmp$ time ./a.out
^C

real	8m11.002s
user	0m0.100s
sys	7m54.726s
hirenp at firebird:/tmp$
----

not sure how useful this really is to get an idea, but sync is clearly 
to be avoided as you mentioned. what do you guys make of the difference 
between fsync and no fsync in relation to nagios?

> 
> Observation:
> 
> I think that the retention.dat and other files that are important to 
> retain across crashes would definitely benefit from the fsync. Though 
> nagios would still work across such a failure, I would rather that data 
> be preserved properly, especially when we have a retention.dat file that 
> is 40MB and the rescheduling, etc. would be handled so much more 
> effectively. So for what it is worth, I think it important that those 
> files be fsync'd.
> 

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july