Re: Filesystem benchmarking for pg 8.3.3 server - Mailing list pgsql-performance

From Ron Mayer
Subject Re: Filesystem benchmarking for pg 8.3.3 server
Date
Msg-id 48A2F297.9030703@cheapcomplexdevices.com
Whole thread Raw
In response to Re: Filesystem benchmarking for pg 8.3.3 server  (Greg Smith <gsmith@gregsmith.com>)
Responses Re: Filesystem benchmarking for pg 8.3.3 server  ("Scott Marlowe" <scott.marlowe@gmail.com>)
Re: Filesystem benchmarking for pg 8.3.3 server  (Greg Smith <gsmith@gregsmith.com>)
List pgsql-performance
Greg Smith wrote:
> The below disk writes impossibly fast when I issue a sequence of fsync

'k.  I've got some homework. I'll be trying to reproduce similar
with md raid, old IDE drives, etc to see if I can reproduce them.
I assume test_fsync in the postgres source distribution is
a decent way to see?

> driver hacker Jeff Garzik says "It's completely ridiculous that we
> default to an unsafe fsync."

Yipes indeed.  Still makes me want to understand why people
claim IDE suffers more than SCSI, tho.  Ext3 bugs seem likely
to affect both to me.

> writes to it under the CentOS 5 Linux I was running on it. ...
> junk from circa 2004, and it's worth noting that it's an ext3 filesystem
> in a md0 RAID-1 array (aren't there issues with md and the barriers?)

Apparently various distros vary a lot in how they're set
up (SuSE apparently defaults to mounting ext3 with the barrier=1
option; other distros seemed not to, etc).

I'll do a number of experiments with md, a few different drives,
etc. today and see if I can find issues with any of the
drives (and/or filesystems) around here.

But I still am looking for any evidence that there were any
widely shipped SATA (or even IDE drives) that were at fault,
as opposed to filesystem bugs and poor settings of defaults.

pgsql-performance by date:

Previous
From: Ron Mayer
Date:
Subject: Re: Filesystem benchmarking for pg 8.3.3 server
Next
From: "Scott Marlowe"
Date:
Subject: Re: Filesystem benchmarking for pg 8.3.3 server