[kdepim-users] Frequent coruptions of data base. Any remedies?
Stephan Diestelhorst
stephan.diestelhorst at gmail.com
Thu Dec 29 13:25:57 GMT 2011
On 27 December 2011 14:50, Martin Steigerwald <Martin at 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
More information about the kdepim-users
mailing list