Skip site navigation (1) Skip section navigation (2)

Re: Raw devices vs. Filesystems

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Chris Browne <cbbrowne(at)acm(dot)org>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: Raw devices vs. Filesystems
Date: 2004-04-07 05:26:02
Message-ID: 5719.1081315562@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-adminpgsql-performance
Chris Browne <cbbrowne(at)acm(dot)org> writes:
> That claim seems really rather remarkable.
> It implies an entirely stunning degree of inefficiency in the
> implementation of filesystems on Solaris.

Solaris has a reputation for having stunning degrees of inefficiency
in a number of places :-(.  On the other hand I've also heard it praised
for its ability to survive partial hardware failures (eg, N out of M
CPUs down), so maybe that's the price you gotta pay.

But to get back to the point of this discussion: to allow PG to use raw
devices instead of filesystems, we'd first have to do a ton of
portability work (since raw disk access is nowhere standard), and
abandon our principle that Postgres does not run as root (since raw disk
access is not permitted to non-root processes by any sane sysadmin).
But that last is a mighty comforting principle to have, anytime someone
complains that their el cheapo whitebox PC locks up as soon as they
start to stress the database.  I know I'd have wasted a lot more time
chasing random hardware breakages if I couldn't say "system freezes and
filesystem corruption are Clearly Not Our Fault".

After that, we get to implement our own filesystem-equivalent management
of disk space allocation, disk I/O scheduling, etc.  Are we really
smarter than all those kernel hackers doing this for a living?  I doubt it.

After that, we get to re-optimize all the existing Postgres behaviors
that are designed to sit on top of a standard Unix buffering filesystem
layer.

After that, we might reap some performance benefits.  Or maybe not.
There's not a heck of a lot of hard evidence that we would --- and
what there is traces to twenty-year-old assumptions about disk drive
and OS behavior, which are quite unlikely to still apply today.

Personally, I have a lot of more-promising projects to pursue...

			regards, tom lane

In response to

Responses

pgsql-performance by date

Next:From: Heiko KehlenbrinkDate: 2004-04-07 07:06:41
Subject: Re: performance comparission postgresql/ms-sql server
Previous:From: huang yaqinDate: 2004-04-07 04:00:37
Subject: Re: good pc but bad performance,why?

pgsql-admin by date

Next:From: Tom LaneDate: 2004-04-07 06:07:57
Subject: Re: restoring large objects
Previous:From: Marsh RayDate: 2004-04-07 02:56:38
Subject: Re: Raw devices vs. Filesystems

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group