choosing a file system

Janne Peltonen janne.peltonen at helsinki.fi
Thu Jan 8 10:20:00 EST 2009


Hm.

ReiserFS:

If I'm still following after reading through all this discussion,
everyone who is actually using ReiserFS (v3) appears to be very content
with it, even with very large installations. Apparently the fact that
ReiserFS uses the BKL in places doesn't hurt performance too badly, even
with multi core systems? Another thing I don't recall being mentioned
was fragmentation - ext3 appears to have a problem with it, in typical
Cyrus usage, but how does ReiserFS compare to it?

Also, the write barrier problem mentioned in response to my earlier post
on ext3 would apparently be there with ReiserFS, too, wouldn't it?

GFS:

Nobody mentioned using GFS, which /is/ a clustered file system and as
such, probably overkill if it's only mounted on one node at a time, but
I'm curious... the overhead of a clustered FS is the fact that all
metadata operations take a long time, because there is a lot of
cluster-wide locking. But how much metadata operations there are, after
all, in Cyrus?

Also, GFS is one of the two file systems available when using RH
clustering...

Ext3:

I'm using this happily, with 50k users, 24 distinct mailspools of 240G
each. Full backups take quite a while to complete (~2 days), but normal
usage is quite fast. There is the barrier problem, of course... I'm
using noatime (implying nodiratime) and data=ordered, since
data=writeback resulted in corrupted skiplist files on crash, while
data=ordered mostly didn't.

Also, ext3 is the other FS available when using RH clustering. (Of
course, it isn't a clustered FS, so it is only available when using the
cluster in active-passive mode.)

XFS:

There was someone using this, too, and happy with it.

JFS:

Mm, apparently no comments on this, not positive, at least.

Future:

Ext4 just got stable, so there is no real world Cyrus user experience on
it. Among other things, it contains an online defragmenter. Journal
checksumming might also help around the write barrier problem on LVM
logical volumes, if I've understood correctly.

Reiser4 might have a future, at least Andrew Morton's -mm patch contains
it and there are people developing it. But I don't know if it ever will
be included in the "standard" kernel tree.

Btrfs is in so early development that I don't know yet what to say about
it, but the fact of ZFS's being incompatible with GPL might be mitigated
by this.

Conclusion:

I'm going to continue using ext3 for now, and probably ext4 when it's
available from certain commercial enterprise linux vendor (personally,
I'd be using Debian, but the department has an official policy of using
RH / Centos). I'm eagerly waiting for btrfs to appear... I probably /would/
switch to ReiserFS for now, if RH cluster would support ReiserFS FS
resources.  Hmm, maybe I should just start hacking... On the other hand,
the upgrade path from ext3 to ext4 is quite easy, and I don't know yet
which would be better, ReiserFS or ext4.


-- 
Janne Peltonen <janne.peltonen at helsinki.fi> PGP Key ID: 0x9CFAC88B
Please consider membership of the Hospitality Club (http://www.hospitalityclub.org)


More information about the Info-cyrus mailing list