Thanks for the info.
I managed to pull out some archived posts to this list from the PostgreSQL
web site about this issue which have helped a bit.
Unfortunatly, the FS has been chosen before considering the impact of it on
I/O for PostgreSQL. As the Cluster is sitting on it's on 200GB IDE drive for
the moment and the system is partially live, it's not feasable to change the
underlying file system without great pain and suffering.
In the great fsync debates that I've seen, the pervasive opinion about
journalling file systems under Linux and PostgreSQL is to have the
filesystem mount option data=writeback, assuming that fsync in PostgreSQL
will handle coherency of the file data and the FS will handle metadata.
This is all academic to a point, as tuning the FS will get a small
improvement on I/O compared to the improvement potential of moving to
SCSI/FCAL, that and getting more memory.
Regards,
Pete de Zwart.
"Christopher Browne" <cbbrowne@acm.org> wrote in message
news:m3zmzgayzl.fsf@knuth.knuth.cbbrowne.com...
> Your understanding of the impact of filesystem journalling isn't
> entirely correct. In the cases of interest, journalling is done on
> metadata, not on the contents of files, with the result that there
> isn't really that much overlap between the two forms of "journalling"
> that are taking place.
>
> I did some benchmarking last year that compared, on a write-heavy
> load, ext3, XFS, and JFS.
>
> I found that ext3 was materially (if memory serves, 15%) slower than
> the others, and that there was a persistent _slight_ (a couple
> percent) advantage to JFS over XFS.
>
> This _isn't_ highly material, particularly considering that I was
> working with a 100% Write load, whereas "real world" work is likely to
> have more of a mixture.
>
> If you have reason to consider one filesystem or another better
> supported by your distribution vendor, THAT is a much more important
> reason to pick a particular filesystem than 'raw speed.'
