On Thu, 20 Jan 2005, Joshua D. Drake wrote:
Is there any evidence of the above claim? I've seen a link to a l-k bug report about ext3, but apparently it was totally unconfirmed (and a single bug does not mean a FS is not good - I remember XFS being hammered heavily before being accepted into Linux).
EXT3 works. It is just dog slow and yes there is plenty of evidence to EXT3s problems. Even from the author himself. Just review the kernel threads and mailing lists. Note that a lot of the problem have been fixed.
It's just that EXT3 bugs are exposed, and discussed in the wild.
Again, please provide this "evidence", expecially for the "dog slow" part.
As for problems, I don't count bugs, expecially already fixed ones, as problems. A "problem" to me is something you can't correct and have to live with it. As a design flaw. EXT3 for sure has a huge user base, compared to XFS, so counting the number of bug reports on linux-kernel is meaningless, since XFS is a _recent_ addition to the mainstream kernel.
I'm using ext3 cause all other FSes are simple add-ons in linux.All of them struggled a lot before being able to meet linux high
quality standards and being accepted into mainstream. Ext3 was there
from the start. Of course that doesn't mean it fits PostgreSQL needs
better than other FSes.
Well that isnt exactly true. EXT3 is a bolt on to EXT2 which was always there. Reiser is also a long time kernel at least from 2.2. XFS is also a long time Linux supporter and its inclusion into the main tree had nothing to do with quality.
Just because something isn't in the main tree doesn't mean that the quality is lacking. A lot of times it is just politics.
Interesting point of view. When it comes to filesystems, I tend to trust Al Viro's (linux VFS and generic filesystems mantainer) opinion.
http://lkml.org/lkml/2003/12/2/150
"bloated", "[locking] it's a fscking mess", "long past the point where maintainers had lost any control over it". I see no politics in that. Just plain technical concerns about code quality. That was only one year ago.
Anyway, XFS got merged, so I guess now it's up to tolerable quality, I hope.
But still I don't like this:
http://oss.sgi.com/projects/xfs/faq.html#nulls
It seems it journals only metadata. You need _all_ processes in your system to use fsync or the O_SYNC flag. Otherwise you're going to _loose data_. There's no mount option about that. Compare EXT3 mount options: data=journal, data=ordered, data=writeback. It seems XFS only supports something similar to data=writeback.
EXT3 default mode is data=ordered: "All data is forced directly out to the main file system prior to its metadata being committed to the journal."
No wonder EXT3 (in default mode) may result slower than XFS, it's comparing oranges with apples. PostgreSQL users might not be affected, if they run with fsync on. If the application forces sync operations, I doubt there's any measurable difference between the two filesystems. The storage will be the bottleneck.
There is a reason that all major distributions supported XFS, Reiser and JFS before RedHat and it has nothing to do with quality.
Yes, user demand. Many distros support broken drivers, unstables patches, and lots of stuff that doesn't make it for the vanilla kernel, due to quality concerns. So you're right. It has nothing to do with quality...
EXT3 and XFS have quite different feature sets, and I think both are a valid choice for PostgreSQL systems. Choose depending on your needs. But, please stop spreading FUD about EXT3, unless you provide direct links to "evidence". Generic "search the lists" isn't enough, I could say the same about XFS, and any other FS, of course. No software is born perfect.
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@xxxxxx---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
