Re: [PERFORM] File Systems Compared

On Fri, Dec 15, 2006 at 10:44:39 -0600, Bruno Wolff III <[EMAIL PROTECTED]> wrote: > > The other feature I would like is to be able to use write barriers with > encrypted file systems. I haven't found anythign on whether or not there > are near term plans by any one to support that. I asked abo

Re: [PERFORM] File Systems Compared

On Fri, Dec 15, 2006 at 10:34:15 -0600, Bruno Wolff III <[EMAIL PROTECTED]> wrote: > The reply wasn't (directly copied to the performance list, but I will > copy this one back. Sorry about this one, I meant to intersperse my replies and hit the 'y' key at the wrong time. (And there ended up bein

Re: [PERFORM] File Systems Compared

On Thu, Dec 14, 2006 at 13:21:11 -0800, Ron Mayer <[EMAIL PROTECTED]> wrote: > Bruno Wolff III wrote: > > On Thu, Dec 14, 2006 at 01:39:00 -0500, > > Jim Nasby <[EMAIL PROTECTED]> wrote: > >> On Dec 11, 2006, at 12:54 PM, Bruno Wolff III wrote: > >>> This appears to be changing under Linux. Rec

Re: [PERFORM] File Systems Compared

The reply wasn't (directly copied to the performance list, but I will copy this one back. On Thu, Dec 14, 2006 at 13:21:11 -0800, Ron Mayer <[EMAIL PROTECTED]> wrote: > Bruno Wolff III wrote: > > On Thu, Dec 14, 2006 at 01:39:00 -0500, > > Jim Nasby <[EMAIL PROTECTED]> wrote: > >> On Dec 11, 2

Re: [PERFORM] File Systems Compared

Bruno Wolff III wrote: > On Thu, Dec 14, 2006 at 01:39:00 -0500, > Jim Nasby <[EMAIL PROTECTED]> wrote: >> On Dec 11, 2006, at 12:54 PM, Bruno Wolff III wrote: >>> This appears to be changing under Linux. Recent kernels have write >>> barriers implemented using cache flush commands (which >>>

Re: [PERFORM] File Systems Compared

On Thu, Dec 14, 2006 at 01:39:00 -0500, Jim Nasby <[EMAIL PROTECTED]> wrote: > On Dec 11, 2006, at 12:54 PM, Bruno Wolff III wrote: > > > >This appears to be changing under Linux. Recent kernels have write > >barriers > >implemented using cache flush commands (which some drives ignore, > >so

Re: [PERFORM] File Systems Compared

On Dec 11, 2006, at 12:54 PM, Bruno Wolff III wrote: On Wed, Dec 06, 2006 at 08:55:14 -0800, Mark Lewis <[EMAIL PROTECTED]> wrote: Anyone run their RAIDs with disk caches enabled, or is this akin to having fsync off? Disk write caches are basically always akin to having fsync off. The only

Re: [PERFORM] File Systems Compared

On Wed, Dec 06, 2006 at 08:55:14 -0800, Mark Lewis <[EMAIL PROTECTED]> wrote: > > Anyone run their RAIDs with disk caches enabled, or is this akin to > > having fsync off? > > Disk write caches are basically always akin to having fsync off. The > only time a write-cache is (more or less) safe t

Re: [PERFORM] File Systems Compared

On 12/6/06, Brian Wipf <[EMAIL PROTECTED]> wrote: > Hmmm. Something is not right. With a 16 HD RAID 10 based on 10K > rpm HDs, you should be seeing higher absolute performance numbers. > > Find out what HW the Areca guys and Tweakers guys used to test the > 1280s. > At LW2006, Areca was demons

Re: [PERFORM] File Systems Compared

On Wed, 6 Dec 2006, Alexander Staubo wrote: Care to post these numbers *without* word wrapping? Brian's message was sent with format=flowed and therefore it's easy to re-assemble into original form if your software understands that. I just checked with two e-mail clients (Thunderbird and Pi

Re: [PERFORM] File Systems Compared

Hmmm. Something is not right. With a 16 HD RAID 10 based on 10K rpm HDs, you should be seeing higher absolute performance numbers. Find out what HW the Areca guys and Tweakers guys used to test the 1280s. At LW2006, Areca was demonstrating all-in-cache reads and writes of ~1600MBps and ~

Re: [PERFORM] File Systems Compared

At 10:40 AM 12/6/2006, Brian Wipf wrote: All tests are with bonnie++ 1.03a Main components of system: 16 WD Raptor 150GB 1 RPM drives all in a RAID 10 ARECA 1280 PCI-Express RAID adapter with 1GB BB Cache (Thanks for the recommendation, Ron!) 32 GB RAM Dual Intel 5160 Xeon Woodcrest 3.0 GH

Re: [PERFORM] File Systems Compared

On Wed, Dec 06, 2006 at 18:45:56 +0100, Markus Schiltknecht <[EMAIL PROTECTED]> wrote: > > Cool, thank you for the example :-) I thought the MTA or at least the the > mailing list would wrap mails at some limit. I've now set word-wrap to > characters (it seems not possible to turn it off

Re: [PERFORM] File Systems Compared

Luke Lonergan wrote: Brian, On 12/6/06 8:40 AM, "Brian Hurt" <[EMAIL PROTECTED]> wrote: But actually looking things up, I see that PCI-Express has a theoretical 8 Gbit/sec, or about 800Mbyte/sec. It's PCI-X that's 533 MByte/sec. So there's still some headroom available there. See h

Re: [PERFORM] File Systems Compared

On 12/6/06, Luke Lonergan <[EMAIL PROTECTED]> wrote: People buy SANs for interesting reasons, some of them having to do with the manageability features of high end SANs. I've heard it said in those cases that "performance doesn't matter much". There is movement in the industry right now away f

Re: [PERFORM] File Systems Compared

On Wed, Dec 06, 2006 at 06:59:12PM +0100, Arnaud Lesauvage wrote: Markus Schiltknecht a écrit : What's common practice? What's it on the pgsql mailing lists? The netiquette usually advise mailers to wrap after 72 characters on mailing lists. This does not apply for format=flowed I guess (that

Re: [PERFORM] File Systems Compared

Markus Schiltknecht a écrit : What's common practice? What's it on the pgsql mailing lists? The netiquette usually advise mailers to wrap after 72 characters on mailing lists. This does not apply for format=flowed I guess (that's the format used in Steinar's message). --

Re: [PERFORM] File Systems Compared

Hi, Steinar H. Gunderson wrote: This is a rather long sentence without any kind of word wrapping except what would be imposed on your own side -- how to set that up properly depends on the sending e-mail client, but in mine it's just a matter of turning off the word wrapping in your editor :-

Re: [PERFORM] File Systems Compared

Brian, On 12/6/06 8:40 AM, "Brian Hurt" <[EMAIL PROTECTED]> wrote: > But actually looking things up, I see that PCI-Express has a theoretical 8 > Gbit/sec, or about 800Mbyte/sec. It's PCI-X that's 533 MByte/sec. So there's > still some headroom available there. See here for the official specifi

Re: [PERFORM] File Systems Compared

> Anyone run their RAIDs with disk caches enabled, or is this akin to > having fsync off? Disk write caches are basically always akin to having fsync off. The only time a write-cache is (more or less) safe to enable is when it is backed by a battery or in some other way made non-volatile. So a R

Re: [PERFORM] File Systems Compared

* Brian Wipf: > Anyone run their RAIDs with disk caches enabled, or is this akin to > having fsync off? If your cache is backed by a battery, enabling write cache shouldn't be a problem. You can check if the whole thing is working well by running this test script:

Re: [PERFORM] File Systems Compared

On Wed, Dec 06, 2006 at 05:31:01PM +0100, Markus Schiltknecht wrote: >> Care to post these numbers *without* word wrapping? Thanks. > How is one supposed to do that? Care giving an example? This is a rather long sentence without any kind of word wrapping except what would be imposed on your own s

Re: [PERFORM] File Systems Compared

Luke Lonergan wrote: Brian, On 12/6/06 8:02 AM, "Brian Hurt" <[EMAIL PROTECTED]> wrote: These numbers are close enough to bus-saturation rates PCIX is 1GB/s + and the memory architecture is 20GB/s+, though each CPU is likely to obtain only 2-3GB/s. We routinely achieve 1GB/s I/O ra

Re: [PERFORM] File Systems Compared

> As you suggest, database replication provides one of those features, and > Solaris ZFS has many of the data management features found in high end SANs. > Perhaps we can get the best of both? > > In the end, I think SAN vs. server storage is a religious battle. I agree. I have many people that

Re: [PERFORM] File Systems Compared

Hi, Alexander Staubo wrote: Care to post these numbers *without* word wrapping? Thanks. How is one supposed to do that? Care giving an example? Markus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster

Re: [PERFORM] File Systems Compared

Brian, On 12/6/06 8:02 AM, "Brian Hurt" <[EMAIL PROTECTED]> wrote: > These numbers are close enough to bus-saturation rates PCIX is 1GB/s + and the memory architecture is 20GB/s+, though each CPU is likely to obtain only 2-3GB/s. We routinely achieve 1GB/s I/O rate on two 3Ware adapters and 2GB

Re: [PERFORM] File Systems Compared

On Dec 6, 2006, at 16:40 , Brian Wipf wrote: All tests are with bonnie++ 1.03a [snip] Care to post these numbers *without* word wrapping? Thanks. Alexander. ---(end of broadcast)--- TIP 4: Have you searched our list archives? htt

Re: [PERFORM] File Systems Compared

Brian Wipf wrote: All tests are with bonnie++ 1.03a Thanks for posting these tests. Now I have actual numbers to beat our storage server provider about the head and shoulders with. Also, I found them interesting in and of themselves. These numbers are close enough to bus-saturation rates

[PERFORM] File Systems Compared

All tests are with bonnie++ 1.03a Main components of system: 16 WD Raptor 150GB 1 RPM drives all in a RAID 10 ARECA 1280 PCI-Express RAID adapter with 1GB BB Cache (Thanks for the recommendation, Ron!) 32 GB RAM Dual Intel 5160 Xeon Woodcrest 3.0 GHz processors OS: SUSE Linux 10.1 All run