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
Re: Re: New Linux xfs/reiser file systems |
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: