Re: Raw devices vs. Filesystems

From: Grega Bremec <gregab(at)noviforum(dot)si>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Chris Browne <cbbrowne(at)acm(dot)org>, pgsql-admin(at)postgresql(dot)org, pgsql-performance(at)postgresql(dot)org
Subject: Re: Raw devices vs. Filesystems
Date: 2004-04-07 07:18:58
Message-ID: 20040407071858.GA7973@elbereth.noviforum.si
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-performance

...and on Wed, Apr 07, 2004 at 01:26:02AM -0400, Tom Lane used the keyboard:
>
> 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...
>

Has anyone tried PostgreSQL on top of OCFS? Personally, I'm not sure it
would even work, as Oracle clearly state that OCFS was _never_ meant to
be a fully fledged UNIX filesystem with POSIX features such as correct
timestamp updates, inode changes, etc., but OCFSv2 brings some features
that might lead one into thinking they're about to make it suitable for
uses beyond that of just having Oracle databases sitting on top of it.

Furthermore, this filesystem would be a blazing one stop solution for
all replication issues PostgreSQL currently suffers from, as its main
design goal was to present "a consistent file system image across the
servers in a cluster".

Now, if both goals can be achieved in one go, hell, I'm willing to try
it out myself in an attempt to extract off of it, some performance
indicators that could be compared to other database performance tests
sent to both this and the PERFORM mailing list.

So, anyone? :)

Cheers,
--
Grega Bremec
Senior Administrator
Noviforum Ltd., Software & Media
http://www.noviforum.si/

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Marion McKelvie 2004-04-07 07:43:50 Re: restoring large objects
Previous Message Tom Lane 2004-04-07 06:07:57 Re: restoring large objects

Browse pgsql-performance by date

  From Date Subject
Next Message Richard Huxton 2004-04-07 08:33:12 Re: good pc but bad performance,why?
Previous Message Heiko Kehlenbrink 2004-04-07 07:06:41 Re: performance comparission postgresql/ms-sql server