Re: Filesystem vs. Postgres for images

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Christopher Petrilli <petrilli(at)amber(dot)org>
Cc: Jeremiah Jahn <jeremiah(at)cs(dot)earlham(dot)edu>, postgres list <pgsql-general(at)postgresql(dot)org>
Subject: Re: Filesystem vs. Postgres for images
Date: 2004-04-13 15:27:42
Message-ID: Pine.LNX.4.33.0404130925320.28757-100000@css120.ihs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, 13 Apr 2004, Christopher Petrilli wrote:

> 2. Retrieval time is limited not by disk bandwidth, but by I/O seek
> performance. More spindles = more concurrent I/O in flight. Also, this
> is where SCSI takes a massive lead with tag-command-queuing.
>
> In our case, we ended up using a three-tier directory structure, so
> that we could manage the number of files per directory, and then
> because load was relatively even across the top 20 "directories", we
> split them onto 5 spindle-pairs (i.e. RAID-1). This is a place where
> RAID-5 is your enemy. RAID-1, when implemented with read-balancing, is
> a substantial performance increase.

Please explain why RAID 5 is so bad here. I would think that on a not
very heavily updated fs, RAID-5 would be the functional equivalent of a
RAID 0 array with one fewer disks, wouldn't it? Or is RAID 0 also a bad
idea (other than the unreliability of it) because it only puts the data on
one spindle, unlike RAID-1 which puts it on many.

In that case >2 drive RAID 1 setups might be a huge win. The linux kernel
certainly supports them, and I think some RAID cards do too.

Just wondering.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Phil Endecott 2004-04-13 15:41:40 Re: Filesystem vs. Postgres for images
Previous Message scott.marlowe 2004-04-13 15:08:57 Re: Data Encryption in PostgreSQL, and a Tutorial.