experience with one or the other file system. From that I can tell, that I have
made good experience with UFS, EXT2, and XFS. I made catastrophic ex-
perience with ReiserFS (not during operation but you are a looser when it fails
because the recovery methods are likely to be insufficient)
So at the end if somebody runs technical equipment, regardless whether it's a computer or a chemical fab. It can fail and you need to make up your mind about contingency.
This is due even before you start operating the equipment.
So waste too much time on thinking about the perfect file system. But evaluate
the potential damage that can result from failure. Develop a Backup&Recovery
strategy and test it, test it and test it again, so that you can do it blindly when it's
I wish there were more "hard and fast" conclusions to draw, to be able to conclusively say that one or another Linux filesystem was unambiguously preferable for use with PostgreSQL. There are not conclusive metrics, either in terms of speed or of some notion of "reliability." I'd expect ReiserFS to be the poorest choice, and for XFS to be the best, but I only have fuzzy reasons, as opposed to metrics.
The absence of measurable metrics of the sort is _NOT_ a proof that (say) FreeBSD is conclusively preferable, whatever your own preferences (I'll try to avoid characterizing it as "prejudices," as that would be unkind) may be. That would represent a quite separate debate, and one that doesn't belong here, certainly not on a thread where the underlying question was "Which Linux FS is preferred?"
If the OSDB TPC-like benchmarks can get "packaged" up well enough to
easily run and rerun them, there's hope of getting better answers,
perhaps even including performance metrics for *BSD. That, not
Linux-baiting, is the answer...
---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly