On Tue, 9 Mar 2010, Pierre C wrote:
On Tue, 09 Mar 2010 08:00:50 +0100, Greg Smith <greg@xxxxxxxxxxxxxxx> wrote:
Scott Carey wrote:
For high sequential throughput, nothing is as optimized as XFS on Linux
yet. It has weaknesses elsewhere however.
When files are extended one page at a time (as postgres does) fragmentation
can be pretty high on some filesystems (ext3, but NTFS is the absolute worst)
if several files (indexes + table) grow simultaneously. XFS has delayed
allocation which really helps.
I'm curious what you feel those weaknesses are.
Handling lots of small files, especially deleting them, is really slow on
XFS.
Databases don't care about that.
accessing lots of small files works really well on XFS compared to ext* (I
use XFS with a cyrus mail server which keeps each message as a seperate
file and XFS vastly outperforms ext2/3 there). deleting is slow as you say
David Lang
There is also the dark side of delayed allocation : if your application is
broken, it will manifest itself very painfully. Since XFS keeps a lot of
unwritten stuff in the buffers, an app that doesn't fsync correctly can lose
lots of data if you don't have a UPS.
Fortunately, postgres handles fsync like it should be.
A word of advice though : a few years ago, we lost a few terabytes on XFS
(after that, restoring from backup was quite slow !) because a faulty SCSI
cable crashed the server, then crashed it again during xfsrepair. So if you
do xfsrepair on a suspicious system, please image the disks first.
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
