Just to add another story...
I've been running PostgreSQL on Linux since the 6.x days and back then I was
almost always on IDE drives with an EXT2 filesystem. To date, the worse class of
experiences I've had was going through the fs recovery steps for EXT2. In
those cases I never lost data in the database even when I might have lost files.
Once XFS became an in kernel option for Linux, I moved almost all my servers to
that filesystem whether they are IDE or SCSI. In a recent experience where I
was forced to hard reset a server with XFS and IDE drives, the box came right
back up with no data loss.
There is only one case of a major "problem" I've have in the last 8 years or so
and I posted to this list and with Tom's help I was able to get the box online.
That wasn't a filesystem problem though. Its off topic but (for those
interested) that thread, "Database Recovery Procedures", was from September 16,
2003. It had to deal with padding out one of the pg_clog files in a 7.3.x system.
Quoting "Welty, Richard" <richard.welty@bankofamerica.com>:
> Wes Williams writes:
> >Even with a primary UPS on the *entire PostgreSQL server* does one still
> >need, or even still recommend, a battery-backed cache on the RAID
> controller
> >card? [ref SCSI 320, of course]
>
> >If so, I'd be interest in knowing briefly why.
>
> it can be a lot faster.
>
> if the raid controller knows it has a battery backup, then it'll be free
> to do whatever it sees fit in terms of write order.
>
> some controllers (the ibm serveraid 4 units that i have a couple of, for
> example) won't do this unless they know the battery is there, they have no
> option for overriding that setting.
>
> richard
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>
--
Keith C. Perry, MS E.E.
Director of Networks & Applications
VCSN, Inc.
http://vcsn.com
____________________________________
This email account is being host by:
VCSN, Inc : http://vcsn.com