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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On 28/05/13 14:10, Anthony Sheetz wrote:
> 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.

I would like to avoid reinstalling my whole OS, and I don't have a spare
HDD, so isn't there anyway I can reproduce the full disk encryption
using a partition?

> 
> 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