Re: Best Linux Distribution - Mailing list pgsql-general

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@ESI.it