Scott Marlowe wrote:
> On Sun, Dec 7, 2008 at 10:59 PM, M. Edward (Ed) Borasky
> <[EMAIL PROTECTED]> wrote:
>> Ah, but shouldn't a PostgreSQL (or any other database, for that matter)
>> have its own set of filesystems tuned to the application's I/O patterns?
>> Sure, there are some people who need
On Mon, 8 Dec 2008, Scott Marlowe wrote:
On Sun, Dec 7, 2008 at 10:59 PM, M. Edward (Ed) Borasky
<[EMAIL PROTECTED]> wrote:
Ah, but shouldn't a PostgreSQL (or any other database, for that matter)
have its own set of filesystems tuned to the application's I/O patterns?
Sure, there are some peopl
On Sun, Dec 7, 2008 at 10:59 PM, M. Edward (Ed) Borasky
<[EMAIL PROTECTED]> wrote:
> Ah, but shouldn't a PostgreSQL (or any other database, for that matter)
> have its own set of filesystems tuned to the application's I/O patterns?
> Sure, there are some people who need to have all of their eggs in
M. Edward (Ed) Borasky wrote:
Ah, but shouldn't a PostgreSQL (or any other database, for that matter)
have its own set of filesystems tuned to the application's I/O patterns?
Sure, there are some people who need to have all of their eggs in one
basket because they can't afford multiple baskets.
Bruce Momjian wrote:
> Mark Mielke wrote:
>> Greg Smith wrote:
>>> On Fri, 15 Aug 2008, Bruce Momjian wrote:
'data=writeback' is the recommended mount method for that file
system, though I see that is not mentioned in our official
documentation.
>>> While writeback has good perform
Mark Mielke wrote:
> Greg Smith wrote:
> > On Fri, 15 Aug 2008, Bruce Momjian wrote:
> >> 'data=writeback' is the recommended mount method for that file
> >> system, though I see that is not mentioned in our official
> >> documentation.
> > While writeback has good performance characteristics, I
On Fri, Aug 15, 2008 at 12:22 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Mark Wong wrote:
>> On Mon, Aug 4, 2008 at 10:04 PM, <[EMAIL PROTECTED]> wrote:
>> > On Mon, 4 Aug 2008, Mark Wong wrote:
>> >
>> >> Hi all,
>> >>
>> >> We've thrown together some results from simple i/o tests on Linux
>>
Greg Smith wrote:
On Fri, 15 Aug 2008, Bruce Momjian wrote:
'data=writeback' is the recommended mount method for that file
system, though I see that is not mentioned in our official
documentation.
While writeback has good performance characteristics, I don't know
that I'd go so far as to suppo
On Fri, 15 Aug 2008, Bruce Momjian wrote:
'data=writeback' is the recommended mount method for that file system,
though I see that is not mentioned in our official documentation.
While writeback has good performance characteristics, I don't know that
I'd go so far as to support making that an
On Fri, Aug 15, 2008 at 12:22 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Mark Wong wrote:
>> On Mon, Aug 4, 2008 at 10:04 PM, <[EMAIL PROTECTED]> wrote:
>> > On Mon, 4 Aug 2008, Mark Wong wrote:
>> >
>> >> Hi all,
>> >>
>> >> We've thrown together some results from simple i/o tests on Linux
>>
Mark Wong wrote:
> On Mon, Aug 4, 2008 at 10:04 PM, <[EMAIL PROTECTED]> wrote:
> > On Mon, 4 Aug 2008, Mark Wong wrote:
> >
> >> Hi all,
> >>
> >> We've thrown together some results from simple i/o tests on Linux
> >> comparing various file systems, hardware and software raid with a
> >> little bi
On Thu, 7 Aug 2008, Mark Mielke wrote:
Now, modern Linux distributions default to "relatime"
Right, but Mark's HP test system is running Gentoo.
(ducks)
According to http://brainstorm.ubuntu.com/idea/2369/ relatime is the
default for Fedora 8, Mandriva 2008, Pardus, and Ubuntu 8.04.
Anywa
On Thu, Aug 7, 2008 at 3:08 PM, Mark Mielke <[EMAIL PROTECTED]> wrote:
> Andrej Ricnik-Bay wrote:
>
> 2008/8/8 Scott Marlowe <[EMAIL PROTECTED]>:
>
>
> noatime turns off the atime write behaviour. Or did you already know
> that and I missed some weird post where noatime somehow managed to
> slow d
On Thu, Aug 7, 2008 at 3:08 PM, Mark Mielke <[EMAIL PROTECTED]> wrote:
> Andrej Ricnik-Bay wrote:
>
> 2008/8/8 Scott Marlowe <[EMAIL PROTECTED]>:
>
>
> noatime turns off the atime write behaviour. Or did you already know
> that and I missed some weird post where noatime somehow managed to
> slow d
On Thu, Aug 7, 2008 at 3:08 PM, Mark Mielke <[EMAIL PROTECTED]> wrote:
> Andrej Ricnik-Bay wrote:
>
> 2008/8/8 Scott Marlowe <[EMAIL PROTECTED]>:
>
>
> noatime turns off the atime write behaviour. Or did you already know
> that and I missed some weird post where noatime somehow managed to
> slow d
[EMAIL PROTECTED]; pgsql-
>> [EMAIL PROTECTED]; Gabrielle Roth
>> Subject: Re: [PERFORM] file system and raid performance
>>
>
>> I have heard of one or two situations where the combination of the
>> disk controller caused bizarre behaviors with different jou
Andrej Ricnik-Bay wrote:
2008/8/8 Scott Marlowe <[EMAIL PROTECTED]>:
noatime turns off the atime write behaviour. Or did you already know
that and I missed some weird post where noatime somehow managed to
slow down performance?
Scott, I'm quite aware of what noatime does ... you didn'
On Thu, Aug 7, 2008 at 3:57 PM, Andrej Ricnik-Bay
<[EMAIL PROTECTED]> wrote:
> 2008/8/8 Scott Marlowe <[EMAIL PROTECTED]>:
>> noatime turns off the atime write behaviour. Or did you already know
>> that and I missed some weird post where noatime somehow managed to
>> slow down performance?
>
> Sco
> -Original Message-
> From: Mark Wong [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 07, 2008 12:37 PM
> To: Mario Weilguni
> Cc: Mark Kirkwood; [EMAIL PROTECTED]; [EMAIL PROTECTED]; pgsql-
> [EMAIL PROTECTED]; Gabrielle Roth
> Subject: Re: [PERFORM] file system
2008/8/8 Scott Marlowe <[EMAIL PROTECTED]>:
> noatime turns off the atime write behaviour. Or did you already know
> that and I missed some weird post where noatime somehow managed to
> slow down performance?
Scott, I'm quite aware of what noatime does ... you didn't miss a post, but
if you look
On Thu, Aug 7, 2008 at 2:59 PM, Andrej Ricnik-Bay
<[EMAIL PROTECTED]> wrote:
> To me it still boggles the mind that noatime should actually slow down
> activities on ANY file-system ... has someone got an explanation for
> that kind of behaviour? As far as I'm concerned this means that even
> to a
To me it still boggles the mind that noatime should actually slow down
activities on ANY file-system ... has someone got an explanation for
that kind of behaviour? As far as I'm concerned this means that even
to any read I'll add the overhead of a write - most likely in a disk-location
slightly of
On Thu, Aug 7, 2008 at 3:21 AM, Mario Weilguni <[EMAIL PROTECTED]> wrote:
> Mark Kirkwood schrieb:
>>
>> Mark Kirkwood wrote:
>>>
>>> You are right, it does (I may be recalling performance from my other
>>> machine that has a 3Ware card - this was a couple of years ago...) Anyway,
>>> I'm thinking
Mark Kirkwood schrieb:
Mark Kirkwood wrote:
You are right, it does (I may be recalling performance from my other
machine that has a 3Ware card - this was a couple of years ago...)
Anyway, I'm thinking for the Hardware raid tests they may need to be
specified.
FWIW - of course this somewha
Mark Kirkwood wrote:
You are right, it does (I may be recalling performance from my other
machine that has a 3Ware card - this was a couple of years ago...)
Anyway, I'm thinking for the Hardware raid tests they may need to be
specified.
FWIW - of course this somewhat academic given that th
Gregory S. Youngblood wrote:
From: Mark Kirkwood [mailto:[EMAIL PROTECTED]
Mark Wong wrote:
On Mon, Aug 4, 2008 at 10:56 PM, Gregory S. Youngblood
<[EMAIL PROTECTED]> wrote:
I recently ran some tests on Ubuntu Hardy Server (Linux) comparing
JFS, XFS,
and ZFS+FU
Mark Wong wrote:
On Mon, Aug 4, 2008 at 10:56 PM, Gregory S. Youngblood <[EMAIL PROTECTED]>
wrote:
I recently ran some tests on Ubuntu Hardy Server (Linux) comparing JFS, XFS,
and ZFS+FUSE. It was all 32-bit and on old hardware, plus I only used
bonnie++, so the numbers are really only usefu
> From: Mark Kirkwood [mailto:[EMAIL PROTECTED]
> Mark Wong wrote:
> > On Mon, Aug 4, 2008 at 10:56 PM, Gregory S. Youngblood
> <[EMAIL PROTECTED]> wrote:
> >
> >> I recently ran some tests on Ubuntu Hardy Server (Linux) comparing
> JFS, XFS,
> >> and ZFS+FUSE. It was all 32-bit and on old hardware
On Tue, Aug 5, 2008 at 4:54 AM, Mark Wong <[EMAIL PROTECTED]> wrote:
> Hi all,
Hi
> We've thrown together some results from simple i/o tests on Linux
> comparing various file systems, hardware and software raid with a
> little bit of volume management:
>
> http://wiki.postgresql.org/wiki/HP_ProLi
On Mon, Aug 4, 2008 at 10:56 PM, Gregory S. Youngblood <[EMAIL PROTECTED]>
wrote:
> I recently ran some tests on Ubuntu Hardy Server (Linux) comparing JFS, XFS,
> and ZFS+FUSE. It was all 32-bit and on old hardware, plus I only used
> bonnie++, so the numbers are really only useful for my hardware
On Mon, Aug 4, 2008 at 10:04 PM, <[EMAIL PROTECTED]> wrote:
> On Mon, 4 Aug 2008, Mark Wong wrote:
>
>> Hi all,
>>
>> We've thrown together some results from simple i/o tests on Linux
>> comparing various file systems, hardware and software raid with a
>> little bit of volume management:
>>
>> htt
I recently ran some tests on Ubuntu Hardy Server (Linux) comparing JFS, XFS,
and ZFS+FUSE. It was all 32-bit and on old hardware, plus I only used
bonnie++, so the numbers are really only useful for my hardware.
What parameters were used to create the XFS partition in these tests? And,
what optio
On Mon, 4 Aug 2008, Mark Wong wrote:
Hi all,
We've thrown together some results from simple i/o tests on Linux
comparing various file systems, hardware and software raid with a
little bit of volume management:
http://wiki.postgresql.org/wiki/HP_ProLiant_DL380_G5_Tuning_Guide
What I'd like to
Hi all,
We've thrown together some results from simple i/o tests on Linux
comparing various file systems, hardware and software raid with a
little bit of volume management:
http://wiki.postgresql.org/wiki/HP_ProLiant_DL380_G5_Tuning_Guide
What I'd like to ask of the folks on the list is how rele
34 matches
Mail list logo
