On Tue, 9 Mar 2010, Pierre C wrote:
> On Tue, 09 Mar 2010 08:00:50 +0100, Greg Smith <greg@2ndquadrant.com> 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.