[Top] [All Lists]

Re: XFS and XEN

To: xfs@xxxxxxxxxxx
Subject: Re: XFS and XEN
From: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>
Date: Tue, 3 Mar 2009 21:56:17 +0100
In-reply-to: <20090224163823.GA19811@xxxxxxxxxxxxx>
Organization: it-management http://it-management.at
References: <200902170959.55077@xxxxxx> <200902241604.29566@xxxxxx> <20090224163823.GA19811@xxxxxxxxxxxxx>
User-agent: KMail/1.10.3 (Linux/; KDE/4.1.3; x86_64; ; )
On Dienstag 24 Februar 2009 Christoph Hellwig wrote:
> The difference is just that you actually see the
> corruption on XFS while it's pretty silent on extN.  If your Hardware
> (or Hypervisor) is not reliable you _will_ lose data.  Either
> silently or with a spectacular blowup if the filesystem actually has
> consistency checking (which XFS has a lot).

One more question: My hardware should be reliable: RAID controller, 
battery backed cache, disk write cache=off. So even in the event of a 
power fail, nothing should happen. The controller should write open 
blocks after reboot.

But it doesn't. I've retested: power off. On bootup, the XEN domU 
PostgreSQL reported errors again. This time of course I had a good 
backup from a minute before. But still: Shouldn't it be impossible for 
such an error to happen, as my hardware shouldn't eat any data? I'm 
trying to find out where the DB gets destroyed. Is it that "just" 
breaking within a transaction where XEN doesn't correctly fsync is 
enough, despite all hardware else configured well?

Damn, that's a complicated world.

mfg zmi
// Michael Monnerie, Ing.BSc    -----      http://it-management.at
// Tel: 0660 / 415 65 31                      .network.your.ideas.
// PGP Key:         "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38  500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net                  Key-ID: 1C1209B4

<Prev in Thread] Current Thread [Next in Thread>