pg.ddx.io  pgsql-sql@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Shridhar Daithankar <shridhar_daithankar@persistent.co.in>
To: Greg Copeland <greg@copelandconsulting.net>
Cc: pgsql-general <pgsql-general@postgresql.org>
Cc: PostgresSQL Hackers Mailing List <pgsql-hackers@postgresql.org>
Cc: pankaj M. Tolani <pankaj@pspl.co.in>
Subject: Re: [HACKERS] Large databases, performance
Date: Thu, 03 Oct 2002 22:00:18 +0530
Message-ID: <3D9CBDF2.27020.A9CACCF@localhost> (raw)
In-Reply-To: <1033662208.13005.22.camel@mouse.copelandconsulting.net>
References: <3D9CB613.1700.A7DEEF0@localhost>

On 3 Oct 2002 at 11:23, Greg Copeland wrote:

> On Thu, 2002-10-03 at 10:56, Shridhar Daithankar wrote:
> > Well, we were comparing ext3 v/s reiserfs. I don't remember the journalling 
> > mode of ext3 but we did a 10 GB write test. Besides converting the RAID to RAID-
> > 0 from RAID-5 might have something to do about it.
> > 
> > There was a discussion on hackers some time back as in which file system is 
> > better. I hope this might have an addition over it..
> 
> 
> Hmm.  Reiserfs' claim to fame is it's low latency with many, many small
> files and that it's journaled.  I've never seem anyone comment about it
> being considered an extremely fast file system in an general computing
> context nor have I seen any even hint at it as a file system for use in
> heavy I/O databases.  This is why Reiserfs is popular with news and
> squid cache servers as it's almost an ideal fit.  That is, tons of small
> files or directories contained within a single directory.  As such, I'm
> very surprised that reiserfs is even in the running for your comparison.
> 
> Might I point you toward XFS, JFS, or ext3, ?  As I understand it, XFS
> and JFS are going to be your preferred file systems for for this type of
> application with XFS in the lead as it's tool suite is very rich and
> robust.  I'm actually lacking JFS experience but from what I've read,
> it's a notch or two back from XFS in robustness (assuming we are talking
> Linux here).  Feel free to read and play to find out for your self.  I'd
> recommend that you start playing with XFS to see how the others
> compare.  After all, XFS' specific claim to fame is high throughput w/
> low latency on large and very large files.  Furthermore, they even have
> a real time mechanism that you can further play with to see how it
> effects your throughput and/or latencies.

I would try that. Once we are thr. with tests at our hands..

Bye
 Shridhar

--
	"The combination of a number of things to make existence worthwhile."	"Yes, 
the philosophy of 'none,' meaning 'all.'"		-- Spock and Lincoln, "The Savage 
Curtain", stardate 5906.4




view thread (48+ messages)  latest in thread

Message-ID: <3D9CBDF2.27020.A9CACCF@localhost>
Permalink:  ../3D9CBDF2.27020.A9CACCF@localhost/
Also on:    postgresql.org/message-id/3D9CBDF2.27020.A9CACCF@localhost

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-sql@postgresql.org
  Cc: shridhar_daithankar@persistent.co.in, greg@copelandconsulting.net, pgsql-general@postgresql.org, pgsql-hackers@postgresql.org, pankaj@pspl.co.in
  Subject: Re: [HACKERS] Large databases, performance
  In-Reply-To: <3D9CBDF2.27020.A9CACCF@localhost>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox