Re: [Xen-devel] BUG: ext3 corruption in domU

[Anthony Sheetz <sheetzam@xxxxxxxxxxx>]

Missed a reply-all...

I would guess the difference is I am using LVM with full disk
encryption. Take a look at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705124 for the
details on exactly how I am able to recreate this bug.
In other words, I use the installer and chose the option to use full
disk encryption and LVM.
I'll be starting with the rest of the testing and data collection
which was requested shortly.

On Fri, May 24, 2013 at 1:48 PM, Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
> On 17/04/13 15:00, Ian Campbell wrote:
>> On Tue, 2013-04-16 at 18:39 +0100, Anthony Sheetz wrote:
>>> (re-sending, first message seems to have gotten lost)
>>>
>>> I was referred here by Ian Campbell ijc@xxxxxxxxxxxxxx from bugs.debian.org.
>>
>> I'm here too (different hat ;-)), thanks for posting it here. I've added
>> some people who know about the block stuff to the CC.
>>
>> Guys, my suspicion is that the issue is that barriers issued by ext3
>> inside the guest aren't making it all the way down the
>> ext3->blkfront->blkback->lvm->dm-crypt->disk chain leading the
>> filesystem to eventually corrupt itself.
>>
>> The issue seems to relate to the use of dm-crypt since
>> ext3->blkfront->blkback->lvm->disk is reported work fine.
>>
>> However there is no problem with the local dom0 ext3 root filesystem
>> which is also in the same lvm VG on the crypt device (i.e.
>> ext3->lvm->dm-crypt->disk), so its not purely a dm-crypt issue. I figure
>> something is up at the blkfront->back link which causes the barriers
>> which blkback is injecting into the block subsystem either don't make it
>> to the dm-crypt layer or do not DTRT once they arrive.
>>
>> I'm not really sure with how to proceed (or how to ask Anthony to
>> proceed) with verifying any part of that hypothesis though.
>>
>> ISTR issues with old vs new style barriers or barriers with no data in
>> them or something, could this be related to that? (or am I thinking of
>> DISCARD?)
>>
>> The issue was initially reported with Squeeze (Jeremy 2.6.32 tree) domU
>> on a Wheezy (mainline 3.2) dom0 but IIRC has also been repeated with
>> Wheezy on Wheezy now so this isn't cross version confusion about barrier
>> semantics AFAICT.
>
> Hello,
>
> I've been trying to reproduce this issue, but so far I haven't been able
> to. I guess I'm missing something, so here are the steps I followed:
>
> First, I've created a primary partition in my HDD, it's sda3, and then
> I've executed the following in order to encrypt it and setup the lvm:
>
> # cryptsetup luksFormat /dev/sda3
> # cryptsetup luksOpen /dev/sda3 crypt
> # pvcreate /dev/mapper/crypt
> # vgcreate crypt /dev/mapper/crypt
> # lvcreate -L 20G crypt -n debian
>
> That gives me a block device /dev/crypt/debian, that I'm attaching to a
> Debian DomU as xvdb, I've created a partition to fill the whole disk and
> formatted it inside the guest using mkfs.ext3.
>
> Then, inside the guest, I've scp'ed a 10G file from a remote host, and
> checked the checksum, everything OK. So far, I've tested with a Dom0
> kernel 3.2.0-0.bpo.4-amd64 and a DomU kernel 3.2.0-0.bpo.4-amd64 and
> 2.6.32-5-xen-amd64, both tests where OK.
>
> Regards, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel