Re: New Linux xfs/reiser file systems - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: New Linux xfs/reiser file systems
Date
Msg-id 200105031541.f43FfOi27094@candle.pha.pa.us
Whole thread Raw
In response to Re: New Linux xfs/reiser file systems  (mlw <markw@mohawksoft.com>)
Responses Re: Re: New Linux xfs/reiser file systems  (bpalmer <bpalmer@crimelabs.net>)
Re: Re: New Linux xfs/reiser file systems  (Michael Samuel <michael@miknet.net>)
List pgsql-hackers
> > 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 that journalizing file systems will almost always be slower on
> an application such as postgres. The journalizing file system is trying to
> maintain data integrity for an application which is also trying to maintain
> data integrity. There will always be extra work involved.

Yes, the problem is that extra work is required on PostgreSQL's part. 
Log-based file systems make sure all the changes get onto the disk in an
orderly way, but I believe it can delay what gets written to the drive. 
PostgreSQL wants to be sure all the data is on the disk, period. 
Unfortunately, the _orderly_ part makes the _fsync_ part do more work. 
By going from ext2 to a log-based file system, we are getting _farther_
from a raw device that if we just sayed with ext2.

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 be worse for PostgreSQL.

> 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 FFS/softupdates have i/o rates near raw speed, with all the
advantages a file system gives us.  I believe most commercial dbs are
moving away from raw devices and toward file systems.  In the old days
the SysV file system was pretty bad at i/o & fragmentation, so they used
raw devices.

> The ability to put indexes on a separate volume from data.
> The ability to put different tables on different volumes.
> And so on.

We certainly need that, but raw devices would not make this any easier,
I think.

> In the short term, I think poor performance on a journalizing file system is to
> be expected, unless there is an IOCTL to tell the FS to leave the files alone
> (and postgres calls it). A Linux HOWTO which informs people that certain file
> systems will have performance issues and why should handle the problem.
> 
> Perhaps we can convince the Linux community to create a "dbfs" which is a
> stripped down simple no nonsense file system designed for applications like
> databases?

It could become a serious problem as people start using reiser/xfs for
their file systems and don't understand the performance problems.  Even
more likely is that they will turn off fsync, thinking reiser doesn't
need it, when in fact, I think it does.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: A problem with pg_dump?
Next
From: Bruce Momjian
Date:
Subject: Re: Unix sockets connection authentication - patch