Re: Re: Bug#637234: linux-image-3.0.0-1-686-pae: I/O errors using ext4 under xen

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Fri, Aug 26, 2011 at 06:58:34PM -0400, Gedalya wrote:
> 
> >One way to make sure that is not the case is to disable barriers in the
> >guest. Meaning in /etc/fstab have something like this:
> >
> >/dev/xvdc /blah     ext4    errors=remount-ro,barrier=0 0 1
> 
> That seems to fix it. It was remounting as read only either during
> the boot process or immediately after, and now it boots up and seems
> to stay up. I'll test laster with a DomU that actually has things
> running.

Yeeey!
> 
> This also fixes the reboot problem I noted earlier, init 6 now
> reboots the DomU rather than destory it.
> 
> >
> >The other question is what version of Dom0 are you running? Is it 2.6.32?
> >2.6.39?
> squeeze, running linux-image-2.6.32-5-xen-amd64  2.6.32-35

Oh, I think I know _exactly_ what bug that is:

This git commit:
280802657fb95c52bb5a35d43fea60351883b2af "xen/blkback: When writting barriers set the sector number to zero"
has to be reverted. Specifically:

commit 3f963cae3ef35d26fdd899c08797a598c5ca3e9b
Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Date:   Tue Jul 19 16:44:42 2011 -0700

    Revert "xen/blkback: When writting barriers set the sector number to zero..."
    
    This reverts commit 280802657fb95c52bb5a35d43fea60351883b2af.  This patch
    is reported to cause disk corruption:
    
    From: "Huang2, Wei" <Wei.Huang2@amd.com>
    
    We recently found a disk corruption issue with SLES11 SP1 guest. Basically
    the guest disk becomes non-bootable after guest shutdown. This is a SLES
    specific issue as we didn’t see on other Linux and Windows VMs. Here
    is the configuration:
    
    ============
    
    1.      Xen: xen-4.1-testing, changeset 23096
    
    2.      Dom0: Jeremy’s latest pvops 6d94b75 (June 1)
    
    3.      VM: SLES 11 SP1, installed as physical machine with raw disk format
    
    ============
    
    Regarding the disk before corruption, “file sles11sp1.img” command
    read: “/root/guests/sles11-sp1/sles11sp1.img: x86 boot sector;
    partition 1: ID=0x82, starthead 1, startsector 63, 4208967 sectors;
    partition 2: ID=0x83, active, starthead 0, startsector 4209030,
    16755795 sectors”. After corruption, it became a data file:
    ““/root/guests/sles11-sp1/sles11sp1.img: data”.


and this one added:

25266338a41470a21e9b3974445be09e0640dda7
xen/blkback: don't fail empty barrier requests
    
    The sector number on empty barrier requests may (will?) be -1, which,
    given that it's being treated as unsigned 64-bit quantity, will almost
    always exceed the actual (virtual) disk's size.
    
    Inspired by Konrad's "When writting barriers set the sector number to
    zero...".