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

[Martin Steigerwald]

Am Donnerstag, 29. Dezember 2011 schrieb Stephan Diestelhorst:
> 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.

From the hardware side this should work. Harddisks should come with at 
least cache flush support by default since quite some time. Some can do FUA 
(Forced Unit Access), but thats not necessary.

> > 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?

This should be safe.

As for tests: With write barriers the filesystem would log a kernel message 
when the first barrier request fails. Usually this is directly after 
mounting with a test barrier request, but on Ext3/4 this is after the first 
write request.

But then write barriers are gone in the meanwhile and the new cache flush 
requests do never fail regardless of the capabilities of the hardware. The 
kernel layers should be safe tough.

You can query the harddisk directly tough:

merkaba:~> hdparm -I /dev/sda | egrep -i "(cache|fua)"
        cache/buffer size  = unknown
           *    Write cache
           *    Mandatory FLUSH_CACHE
           *    FLUSH_CACHE_EXT
           *    WRITE_{DMA|MULTIPLE}_FUA_EXT

This is for an Intel SSD 320. I believce the first FLUSH_CACHE line is the 
only thing that is needed, but I am not completely sure.

> > 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).

I never had any issues with ReiserFS 3, but co-workers had serious data 
corruption. I didn´t use ReiserFS 3 for a long time. So I am not sure 
about how easily ReiserFS eats data. Searching for $FILESYSTEM and 
"corrupt" or yields results for any major filesystem.

But ReiserFS 3 has other disadvantes:
- long mount times on big partitions
- only basic maintenance, no new developments
- ReiserFS can not differentiate between the host ReiserFS and the guest 
ReiserFS when the guest harddisk is stored in an image file on the host 
ReiserFS. So better do not use ReiserFS for the host and the guest. 
Otherwise an fsck might generate a nice mix of both filesystems.

But aside from that the barrier / cache flush stuff from ReiserFS 3 *should* 
work. AFAIR ReiserFS3 received some during the migration to the cache flush 
requests.

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

I doubt its filesystem related unless ReiserFS 3 has a (serious) bug.

I bet its really MySQL choking up here.

Ciao,
-- 
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