Hello !
I am forwarding the following from lkml
It seems that the only case when XFS is slow is the 'rm -rf linux'
[which can be considered as a good sign for linux]. For all other
operation XFS is the winner.
YAS
MessageFromLKML
From: Ricardo Galli ([EMAIL PROTECTED])
Date: Wed May 09 2001
[EMAIL PROTECTED] (Trond Eivind Glomsrød) writes:
[EMAIL PROTECTED] (Trond Eivind Glomsrød) writes:
Ken Hirsch [EMAIL PROTECTED] writes:
I don't have a machine with XFS installed and it will be at least a week
before I could get around to a build. Any volunteers?
I think I
PROTECTED];
[EMAIL PROTECTED]
Sent: Wednesday, May 09, 2001 1:24 PM
Subject: Re: [HACKERS] Re: New Linux xfs/reiser file systems
I'm concearned about this because we are going to switch our
fist server to a Journaling FS (on Linux). Searching and asking
I found out that for our short term work
2. The allocation time for raw devices is by far better (near
instantaneous) than creating preallocated files in a
fs. Providing 1 Tb of raw devices is a task of minutes,
creating 1 Tb filsystems with preallocated 2 Gb files is a
task of hours at best.
Filesystem
I don't have a machine with XFS installed and it will be at least a week
before I could get around to a build. Any volunteers?
I think I could do that... any useful benchmarks to run?
Looks like we have expert help here :-) One very interesting question
would imho be, how do we best
[EMAIL PROTECTED] (Trond Eivind Glomsrød) writes:
Ken Hirsch [EMAIL PROTECTED] writes:
I don't have a machine with XFS installed and it will be at least a week
before I could get around to a build. Any volunteers?
I think I could do that... any useful benchmarks to run?
In lack of
I don't mind contributing the script and schema that I used, but one thing
I
failed to mention in my first post is that the first thing the script does
is open connections to 256 databases (all on this same machine), and the
transactions are relatively evenly dispersed among the 256
I think it's worth noting that Oracle has been petitioning the
kernel developers for better raw device support: in other words,
the ability to write directly to the hard disk and bypassing the
filesystem all together.
But there could be other reasons why Oracle would want to do
Lincoln Yeoh [EMAIL PROTECTED] writes:
OK we can do that with symlinks, but is there a PGSQL Recommended or
Standard way to do it, so as to reduce administrative errors, and at least
help improve consistency with multiadmin pgsql installations?
Not yet. There should be support for this. See
Hannu Krosing [EMAIL PROTECTED] writes:
Even the IMHO hardest to solve problem
- RENAME - can
probably be done in a transaction-safe manner by doing a
link(oid.newname) in the
beginning and selective unlink(oid.newname/oldname) at commit time.
Nope. Consider
begin;
At 02:09 AM 5/4/01 -0500, Thomas Swan wrote:
I think it's worth noting that Oracle has been petitioning the
kernel developers for better raw device support: in other words,
the ability to write directly to the hard disk and bypassing the
filesystem all together.
But there could be other
Lincoln Yeoh wrote:
At 02:09 AM 5/4/01 -0500, Thomas Swan wrote:
I think it's worth noting that Oracle has been petitioning the
kernel developers for better raw device support: in other words,
the ability to write directly to the hard disk and bypassing the
filesystem all together.
Here is a radical idea...
What is it that is causing Postgres trouble? It is the file system's attempts
to maintain some integrity. So I proposed a simple dbfs sort of thing which
was the most basic sort of file system possible.
I'm not sure, but I think we can test this hypothesis on the FAT32
On Thu, May 03, 2001 at 11:41:24AM -0400, Bruce Momjian wrote:
ext2 has serious problems with corrupt file systems after a crash, so I
understand the need to move to another file system type. I have been
waitin for Linux to get a more modern file system. Unfortunately, the
new ones seem to
Michael Samuel wrote:
ReiserFS only supports metadata logging. The performance slowdown must be
due to logging things like mtime or atime, because otherwise ReiserFS is a
very high performance FS. (Although, I admittedly haven't used it since it
was early in it's development)
The way I
Before we get too involved in speculating, shouldn't we actually measure the
performance of 7.1 on XFS and Reiserfs? Since it's easy to disable fsync,
we can test whether that's the problem. I don't think that logging file
systems must intrinsically give bad performance on fsync since they only
mlw [EMAIL PROTECTED] writes:
I have looked at Reiser, and I don't think it is a file system suited for very
large files, or applications such as postgres.
What's the problem with big files? ReiserFS v2 doesn't seem to support
it, while v3 seems just fine (of the ondisk format)
That said,
Bruce == Bruce Momjian [EMAIL PROTECTED] writes:
Well, arguably if you're setting up a database server then a
reasonable DBA should think about such things...
Bruce Yes, but people have trouble installing PostgreSQL. I
Bruce can't imagine walking them through a newfs.
In
Sure, we can do that now. What do we do when these are the default file
systems for Linux? We can tell them to create other types of file
What is a 'default file system' ? I know that untill now, everybody is using
ext2. But that's only because there hasn't been anything comparable. Now we
[ Charset ISO-8859-1 unsupported, converting... ]
Before we get too involved in speculating, shouldn't we actually measure the
performance of 7.1 on XFS and Reiserfs? Since it's easy to disable fsync,
we can test whether that's the problem. I don't think that logging file
systems must
[ Charset ISO-8859-1 unsupported, converting... ]
Sure, we can do that now. What do we do when these are the default file
systems for Linux? We can tell them to create other types of file
What is a 'default file system' ? I know that untill now, everybody is using
ext2. But that's only
On Fri, May 04, 2001 at 08:02:17AM -0400, mlw wrote:
The way I understand it is that ReiserFS does not attempt to separate files at
the block level. Multiple files can live in the same disk block. This is cool
if you have many small files, but the extra overhead for large files such as
mlw wrote:
[EMAIL PROTECTED]">Bruce Momjian wrote:
Just put a note in the installation docs that the place where the databaseis initialised to should be on a non-Reiser, non-XFS mount...Sure, we can do that now. What do we do when these are the default filesystems for Linux? We can tell them
Ken Hirsch [EMAIL PROTECTED] writes:
I don't have a machine with XFS installed and it will be at least a week
before I could get around to a build. Any volunteers?
I think I could do that... any useful benchmarks to run?
--
Trond Eivind Glomsrød
Red Hat, Inc.
Michael Samuel wrote:
Remember, general purpose file systems must do for files what Postgres is
already doing for records. You will always have extra work. I am seriously
thinking of trying a FAT32 as pg_xlog. I wonder if it will improve performance,
or if there is just something
There have been multiple reports of poor PostgreSQL performance on
Reiser and xfs. I don't have numbers, though. Frankly, I think we need
xfs and reiser experts involved to figure out our options here.
I've done some testing to see how Reiserfs performs
vs ext2, and also various for
Joe Conway [EMAIL PROTECTED] wrote:
I've done some testing to see how Reiserfs performs
vs ext2, and also various for various values of wal_sync_method while on a
reiserfs partition. The attached graph shows the results. The y axis is
transactions per second and the x axis is the transaction
I think the XFS and Reiserfs folks will be happy to look at the
performance
problem, but it would be very helpful for them to have a prepackaged
benchmark (or two or three) to use. We should set up an FTP area to
share
them. Joe, can you contribute yours? Does anybody else have anything?
Bruce Momjian wrote:
I was talking to a Linux user yesterday, and he said that performance
using the xfs file system is pretty bad. He believes it has to do with
the fact that fsync() on log-based file systems requires more writes.
With a standard BSD/ext2 file system, WAL writes can
On Thu, 3 May 2001, mlw wrote:
I would bet it is a huge amount of work to use a table space system
and no one wants that.
From some stracing of 7.1, the most common syscall issued by
postgres is an lseek() to the end of the file, presumably to
find its length, which seems to happen up to
Matthew Kirkwood [EMAIL PROTECTED] writes:
From some stracing of 7.1, the most common syscall issued by
postgres is an lseek() to the end of the file, presumably to
find its length, which seems to happen up to about a dozen
times per (pgbench) transaction.
Tablespaces would solve this (not
I know xfs and reiser are both log based. Do we need to be concerned
about PostgreSQL performance on these file systems? I use BSD FFS with
soft updates here, so it doesn't affect me.
I did see poor performance on reiserfs, I have not as yet ventured into using
xfs.
I occurs to me
Matthew Kirkwood [EMAIL PROTECTED] writes:
From some stracing of 7.1, the most common syscall issued by
postgres is an lseek() to the end of the file, presumably to
find its length, which seems to happen up to about a dozen
times per (pgbench) transaction.
Tablespaces would solve
kernel to do it for us. Reimplementing a filesystem doesn't strike me
as a profitable use of our time.)
Ditto. The database is complicated enough.
Maybe some kind of recommendation would be a good thing. That is, if the
PostgreSQL community has enough knowledge.
A section in the docs
This behavior raises the question about file system usage in Postgres. Many
databases, such as Oracle, create table space files and operate directly on the
raw blocks, bypassing the file system altogether.
OK, we have considered this, but frankly, the new, modern file systems
like
On Thu, 3 May 2001, mlw wrote:
This behavior raises the question about file system usage in Postgres. Many
databases, such as Oracle, create table space files and operate directly on the
raw blocks, bypassing the file system altogether.
On one hand, Postgres is easy to use and maintain
; Hackers List
Subject: [HACKERS] Re: New Linux xfs/reiser file systems
Bruce Momjian wrote:
I was talking to a Linux user yesterday, and he said that performance
using the xfs file system is pretty bad. He believes it has to do with
the fact that fsync() on log-based file systems requires more
: [HACKERS] Re: New Linux xfs/reiser file systems
Just put a note in the installation docs that the place where the database
is initialised to should be on a non-Reiser, non-XFS mount...
Sure, we can do that now. What do we do when these are the default file
systems for Linux? We can tell them
Just put a note in the installation docs that the place where the database
is initialised to should be on a non-Reiser, non-XFS mount...
Sure, we can do that now. What do we do when these are the default file
systems for Linux? We can tell them to create other types of file
systems, but that
:[EMAIL PROTECTED]]
Sent: Friday, 4 May 2001 9:42 AM
To: Christopher Kings-Lynne
Cc: mlw; Hackers List
Subject: Re: [HACKERS] Re: New Linux xfs/reiser file systems
Just put a note in the installation docs that the place where the database
is initialised to should be on a non-Reiser, non-XFS
Bruce Momjian wrote:
Just put a note in the installation docs that the place where the database
is initialised to should be on a non-Reiser, non-XFS mount...
Sure, we can do that now. What do we do when these are the default file
systems for Linux? We can tell them to create other
Just put a note in the installation docs that the place where the
database
is initialised to should be on a non-Reiser, non-XFS mount...
Sure, we can do that now.
I still think this is not necessarily the right approach either. One
major purpose of using a journaling fs is for fast boot
42 matches
Mail list logo
