[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdepim-users
Subject:    Re: [kdepim-users] Frequent coruptions of data base. Any remedies?
From:       Stephan Diestelhorst <stephan.diestelhorst () gmail ! com>
Date:       2011-12-29 13:25:57
Message-ID: CAJR39EyshfLTG7MrPaqaxt=KR4Y8Cm_WVMW=apC3UPq7qLDwEQ () mail ! gmail ! com
[Download RAW message or body]

On 27 December 2011 14:50, Martin Steigerwald <Martin@lichtvoll.de> wrote:
> Am Dienstag, 15. November 2011 schrieb Stephan Diestelhorst:
>> >> No, this is on a built-in laptop drive with a LUKS -> LVM -> Reiser
>> >> stack. The problem here is the laptop dieing every now and then
>> >> during suspend / resume, but I'd still have some sane behaviour in
>> >> that case.
>> >
>> > Interesting, I also have to restart my computers from time to time
>> > due to failed resume, but never had a problem with the akonadi
>> > database. I wonder what in the stack is causing the InnoDB
>> > instability. I don't use LVM and use Ext3/4 though...
>>
>> I know, I might be living in the past / on the edge with this setup ;/
>
> Are you using this on a kernel, I/O controller, storage device that holds
> the write barrier / cache flush semantics throughout the whole I/O stack?

So this is a normal laptop (X120e) with standard AMD SB and a Hitachi
standard HDD.

> AFAIR device mapper and especially its crypto target got this consistency
> stuff quite late, while the beginning of this stuff was added back in
> 2.6.16. I could look this up.

This is on a 3.1.4 kernel, so I believe I should be in the clear. Are
you aware of any tests / flags for this feature?

> When these guarentees are not met, there is no database that can hold its
> database integrity in case of crashes or sudden power losses. Cause there
> are no ordered write guarentees of any sort.

Indeed.

> Personally I would replace Reiser with Ext4 or XFS, but then ReiserFS 3 as
> well as Reiser 4 should implement write barrier / cache flushes just well.
> Do you use ReiserFS3 or Reiser 4? I think with Reiser 4 it would be safe
> to say that you use an experimental filesystem and decline any consistency
> guarantees of applications. Like with BTRFS as well. Or then at least say:
> "Go check your filesystem *first*!"

It is ReserFS (aka 3). Just reading through the page on Wikipedia
makes me wanna switch :-) But that will need some preparation (and
enough free space elsewhere).

> Anyway I would first try a recent kernel. And just when that does not work
> retry with Ext4 or XFS. Albeit there are other reasons to switch from
> Reiser to something else…

Kernel: Check
FS: On the TODO list.

Thanks for the suggestions!

Stephan
_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users

[prev in list] [next in list] [prev in thread] [next in thread]