[kdepim-users] Frequent coruptions of data base. Any remedies?

Martin Steigerwald Martin at lichtvoll.de
Tue Dec 27 13:50:02 GMT 2011


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?

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.

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.

So if unsure, I suggest to try with at least a 3.0 kernel.

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*!"

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ā€¦

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users


More information about the kdepim-users mailing list