Re: Frequent coruptions of data base. Any remedies?
Stephan Diestelhorst <[email protected]>
| Newsgroups | gmane.comp.kde.users.pim |
|---|---|
| Message-ID | <CAJR39EyshfLTG7MrPaqaxt=KR4Y8Cm_WVMW=apC3UPq7qLDwEQ@mail.gmail.com> |
On 27 December 2011 14:50, Martin Steigerwald <[email protected]> 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