WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: Bug#637234: linux-image-3.0.0-1-686-pae: I/O errors

To: Gedalya <gedalya@xxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: Bug#637234: linux-image-3.0.0-1-686-pae: I/O errors using ext4 under xen
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Mon, 29 Aug 2011 10:08:50 -0400
Cc: Ian Campbell <ijc@xxxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, 637234@xxxxxxxxxxxxxxx
Delivery-date: Mon, 29 Aug 2011 07:11:07 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E58251A.8090108@xxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20110809180728.2279.11548.reportbug@xxxxxxxxxxxxxxxxx> <1314254828.17978.720.camel@xxxxxxxxxxxxxxxxxxxx> <20110826175317.GA5043@xxxxxxxxxxxx> <4E58251A.8090108@xxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.21 (2010-09-15)
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@xxxxxxxxxx>
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@xxxxxxx>
    
    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...".


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel