Search Postgresql Archives

Re: Filesystem options for storing pg_data

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[I've got a private reply from Scott, which I won't quote here, which
can be fairly (I hope) summarized as "search the pgsql-performance
list". Well, I've done it, and I feel it's due to bring the issue
back in public. So if I seems I'm replying to myself, it's not,
I'm replying to Scott. I've realized the reply was private only
just before sending this out.]
 
> > On Wed, 2005-04-20 at 12:07, Marco Colombo wrote:
> > > On Wed, 2005-04-20 at 11:18 -0500, Scott Marlowe wrote:
> > >
> > > Generally XFS and JFS are considered superior to ext2/3.
> >
> > Do you mind posting a reference? I'm really interested in the comparison
> > but everytime I asked for a pointer, I got no valid resource, so far.
>
[...]

Well, my point being the ones I find lead to the conclusion that EXT3 is
"considered superior" to XFS and JFS. One for all:

http://www.oracle.com/technology/oramag/webcolumns/2002/techarticles/scalzo_linux02.html

"It's reassuring when various industry-standard benchmarks yield similar
results. In case you're wondering, I obtained similar results with
Benchmark Factory's other half dozen or so database benchmarks-so for
me, it'll be ext3."

Have a look at the graphs, EXT3 is almost twice as fast in these
(database) benchmarks.

Another one is:
http://www.kerneltraffic.org/kernel-traffic/kt20020401_160.html#8

Again ext3 is the winner (among journalled fs), but by a small edge
only. And again, there are a lot of variables. Using for example
data=journal with a big journal file on a different disk would
be extremely interesting, just as using a different disk for WALs
is at PostgreSQL level (the result might be the same).

All the other benchmarks I've found, with a simple search for
'filesystem benchmark' on the pgsql-performance list, either are
the usual Bonnie/iozone irrelevant benchmarks, or don't seem to care
to tune ext3 mount options and use the defaults (thus comparing apples
to oranges).

I'm not stating that EXT3 is better. My opinion on the matter is that
you shouldn't care about the filesystem much (EXT3, JFS, XFS being the
same for _most_ purposes with PostgreSQL). That is, it's a small little
spot in the big picture of performance tuning. You'd better look at the
big picture.

I'm only countering your claim: 
"Generally XFS and JFS are considered superior to ext2/3".

There's no general agreement on the lists about that, so just handwaving
and saying "look at the lists" isn't enough. Mind posting a pointer
to _any_ serious PostegreSQL (or any database, at least) based
benchmark that consistently shows XFS and JFS as superior? One that
cares to show ext3/noatime/data=ordered,data=writeback,data=journal
results, too?

If I were to choose based on the results posted on the list (that I've
managed to find), ext3 would be the winner. Maybe I've missed something.

> > > Having used ext3 quite a bit, I'd say it's fairly stable and reliable,
> > > but I have seen references here to know, possibly unfixable bugs.
> > 
> > Again, mind posting a reference?
>
[...]

I've searched for 'EXT3 bug' but got nothing. I'm (loosely) following
l-k, and never heard of "possibly unfixable bugs" in EXT3 by any
developer. Care to post any real reference? There have been bugs of
course, but that holds true for everything, XFS and JFS included.

Having re-read many many messages right now, I'm under a even stronger
impression that _all_ negative comments on both the stability and the
performance of EXT3 start with "I've heard that..." w/o almost noone
providing direct experience. Many comments display little understanding
of the subject: some don't know about data= mount option (there's little
point in comparing to XFS, if you don't use data=writeback), some have
misconceptions about what the option does, and what difference it makes
when the application keeps _syncing_ the files (I don't know well
either). See the data=journal case.

.TM.
-- 
      ____/  ____/   /
     /      /       /                   Marco Colombo
    ___/  ___  /   /                  Technical Manager
   /          /   /                      ESI s.r.l.
 _____/ _____/  _/                      Colombo@xxxxxx


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux