[SGVLUG] SUSE abandoning ReiserFS
dustin at laurences.net
Mon Oct 2 16:08:25 PDT 2006
On Mon, Oct 02, 2006 at 02:22:12PM -0700, Mike Fedyk wrote:
> I may have lost ~5 filesystems because of the reiserfsck tools. That's
> enough for me.
It's not really enough for statistics, but I agree it's enough data to
form some personal prejudices on. There are lots of people who base
such a judgement on one crash--that's why you can find people who claim
that reiserfs and xfs are more reliable than ext3 on cheap PC hardware.
> >reiser also has worse latency than ext, which is why I've abandoned
> >reiserfs and am back to ext exclusively.
> What did you use to measure the latency of the filesystem, and what
> operations were you performing during the measurement?
I'm just passing on the experience of the audio folks who want < 10ms
of latency for hard-disk recording. Lots of them were using reiserfs
because it's fast, but as you know throughput is often the enemy of
latency. It's also the word from Andrew Morton, who told them that they
just weren't going to be able to tune reiserfs to their satisfaction
because of the length of some of the critical sections (I think it was,
this is vague memory).
I have a link to a post by Andrew Morton somewhere on the subject if you
> Ext2 is on average 1.5 or more times faster than ext3. ext2 is still
> the performance king to beat when you don't have to worry about what
> happens after a crash or power outage.
That's my impression. Nice for /tmp and such. Also for hard disk
recording in general (if the power dies you lose the track anyway)
except there you need large filesystems, and fsck'ing enormous ext2
partitions kinda sucks. :-) I believe in practice everyone uses ext3
for that, since again it isn't throughput they care about.
I'm going to rebuild my desktop just for this sort of thing, so I've
been thinking about what I can get away with. :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://www.sgvlug.net/pipermail/sgvlug/attachments/20061002/5d6a380a/attachment.bin
More information about the SGVLUG