Re: [Exim] Re: Large queue sizes - big directories - and Rei…

Top Page
Delete this message
Reply to this message
Author: Marc Perkel
Date:  
To: exim-users
Subject: Re: [Exim] Re: Large queue sizes - big directories - and ReiserFile System
This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
When I used to run Ext2 with redhat 6 - if the server crashed often it
failed to com up on the next boot without someone manually going in and
running fsck with meaner switches. The entire process of rebooting after
a crash often took an hour - and it was a very tense hour - wondering if
it will come up even then.

Since I stated using reiser those probales went away. I also had some
drives (IBM Deathstar) that were slowly dying from sector failures and
in spite of these failures I was amazed with how well it maintained it's
integrity. So - in my experience - I think itr's far more solid that
ext2 and I don't think anyone has to worry that it's ability to recover
is less that ext2.

Nigel Metheringham wrote:

>
>This has actually been one of the major problems with reiser from the
>very start. There have always been reports of the type "I'm using
>reiser and it rocks" and these have been used as evidence of
>reliability. What always appears to have been lacking is evidence of
>resilience and recoverability when something goes wrong.
>
>Ext3 is highly recoverable - I have only once seen a filesystem trashed
>to the point where I decided it was easier to use mkfs as a recovery
>tool and in that case I knew I was running a very early alpha of a
>particular feature set. I have heard (yes anecdotal - but one of the
>sites had been a serious reiser proponent for ages) cases where people
>have just lost reiser partitions for no apparent reason, and were
>completely unable to recover without a reformat and restore.
>
>I am not trying to diss reiser - I have just built a server with reiser
>filesystems as an experiment. However I have consistently had the
>feeling that they put features and speed first, reliability and
>recoverability (which includes from minor hardware glitches) a distant
>second.
>
>    Nigel.

>
>
>

--