Bug#637234: [Xen-devel] Re: Bug#637234: linux-image-3.0.0-1-686-pae: I/O errors using ext4 under xen
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...".
Reply to: