Frequent coruptions of data base. Any remedies?

Hi,
  I get frequent corruptions of my Akonadi data base. One issue is
that the laptop sometimes does not properly suspend / resume and I am
forced to hard power cycle the machine. It seems that the akonadi DB
is very brittle in this regard, despite proper FS restore on the next
boot, I frequently get errors similar to this:

111109 15:08:29 [Note] Plugin 'FEDERATED' is disabled.
111109 15:08:29  InnoDB: Initializing buffer pool, size = 80.0M
111109 15:08:29  InnoDB: Completed initialization of buffer pool
InnoDB: Log scan progressed past the checkpoint lsn 0 699961455
111109 15:08:29  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 0 699963569
111109 15:08:30  InnoDB: Starting an apply batch of log records to the
database...
InnoDB: Progress in percents: 26 27 28 29 30 31 32 33 34 35 36 37 38
39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61
62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84
85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
111109 15:08:30  InnoDB: Started; log sequence number 0 699963569
111109 15:08:30 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.1.54-1ubuntu4'  socket:
'/home/syon/.local/share/akonadi/socket-d-allen/mysql.socket'  port: 0
 (Ubuntu)
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 4479.
InnoDB: You may have to recover from a backup.
111109 15:09:33  InnoDB: Page dump in ascii and hex (16384 bytes):
...
111109 15:09:33  InnoDB: Page checksum 1923164640,
prior-to-4.0.14-form checksum 1959713716
InnoDB: stored checksum 2520600866, prior-to-4.0.14-form stored
checksum 1959713716
InnoDB: Page lsn 0 90554488, low 4 bytes of lsn at page end 90554488
InnoDB: Page number (if stored to page already) 4479,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 11
InnoDB: Page may be an index page where index id is 0 38
InnoDB: (index "PRIMARY" of table "akonadi"."parttable")
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 4479.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.

which makes the whole of Akonadi and PIM unusable.

Is there any way I can gt this thing to work more reliably? Notice
that even if I don't do anything (email client off), virtuoso-t and /
or nepomukservices and akonadi_nepomuk seem to operate on the data.
This is a non-disconnected IMAP resource backing up a large GMail
account (>4 GB, >70000 emails). Is there any setting that makes this
setup less brittle?

Please also note that while I do have to power down the system
uncleanly, there may be other reasons for this corruption in the
database files.

Whenever one of these happens, I usually end up deleting
~/.local/share/akonadi and setting up all the mail servers etc. again.
Is there another, more flexible approach? Would changing to a
different database server / filesystem be advisable?

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