Re: Best OS for Postgres 8.2 - Mailing list pgsql-performance

From david@lang.hm
Subject Re: Best OS for Postgres 8.2
Date
Msg-id Pine.LNX.4.64.0705090150020.2213@asgard.lang.hm
Whole thread Raw
In response to Re: Best OS for Postgres 8.2  (Greg Smith <gsmith@gregsmith.com>)
Responses Re: Best OS for Postgres 8.2
List pgsql-performance
On Tue, 8 May 2007, Greg Smith wrote:

> On Tue, 8 May 2007, Luke Lonergan wrote:
>
>>  From discussions with the developers, the biggest issue is a technical
>>  one: the Linux VFS layer makes the [ZFS] port difficult.
>
> Difficult on two levels.  First you'd have to figure out how to make it work
> at all; then you'd have to reshape it into a form that it would be acceptable
> to the Linux kernel developers, who haven't seemed real keen on the idea so
> far.

given that RAID, snapshots, etc are already in the linux kernel, I suspect
that what will need to happen is for the filesystem to be ported without
those features and then the userspace tools (that manipulate the volumes )
be ported to use the things already in the kernel.

> The standard article I'm you've already seen this week on this topic is Jeff
> Bonwick's at http://blogs.sun.com/bonwick/entry/rampant_layering_violation

yep, that sounds like what I've been hearing.

what the ZFS (and reiserfs4) folks haven't been wanting to hear from the
linux kernel devs is that they are interested in having all these neat
features available for use with all filesystems (and the linux kernel has
a _lot_ of filesystems available), with solaris you basicly have UFS and
ZFS so it's not as big a deal.

> What really bugged me was his earlier article linked to there where he talks
> about how ZFS eliminates the need for hardware RAID controllers:
> http://blogs.sun.com/bonwick/entry/raid_z
>
> While there may be merit to that idea for some applications, like situations
> where you have a pig of a RAID5 volume, that's just hype for database writes.
> "We issue the SYNCHRONIZE CACHE command to the disks after pushing all data
> in a transaction group"--see, that would be the part the hardware controller
> is needed to accelerate.  If you really care about whether your data hit
> disk, there is no way to break the RPM barrier without hardware support.  The
> fact that he misunderstands such a fundamental point makes me wonder what
> other gigantic mistakes might be buried in his analysis.

I've seen similar comments from some of the linux kernel devs, they've
used low-end raid controllers with small processors on them and think that
a second core/socket in the main system to run software raid on is better.

David Lang

pgsql-performance by date:

Previous
From: "Magnus Hagander"
Date:
Subject: Re: Throttling PostgreSQL's CPU usage
Next
From: Guillaume Cottenceau
Date:
Subject: Re: estimating the need for VACUUM FULL and REINDEX