[EMAIL PROTECTED] wrote:
> > I've made a test run that compares fsync and fdatasync: The performance
> > was identical:
> > - with fdatasync:
> > http://khack.osdl.org/stp/290607/
> > - with fsync:
> > http://khack.osdl.org/stp/290483/
> > I don't understand why. Mark - is there a battery backed write cache in
> > the raid controller, or something similar that might skew the results?
> > The test generates quite a lot of wal traffic - around 1.5 MB/sec.
> > Perhaps the writes are so large that the added overhead of syncing the
> > inode is not noticable?
> > Is the pg_xlog directory on a seperate drive?
> > Btw, it's possible to request such tests through the web-interface, see
> > http://www.osdl.org/lab_activities/kernel_testing/stp/script_param.html
> We have 2 Adaptec 2200s controllers, without the battery backed add-on,
> connected to four 10-disk arrays in those systems. I can't think of
> anything off hand that would skew the results.
> The pg_xlog directory is not on a separate drive. I haven't found the
> best way to lay out of the drives on those systems yet, so I just have
> everything on a 28 drive lvm2 volume.
We don't actually extend the WAL file during writes (preallocated), and
the access/modification timestamp is only in seconds, so I wonder of the
OS only updates the inode once a second. What else would change in the
inode more frequently than once a second?
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster