Re: qcow2 becomes 37P in size while qemu crashes

[Chris Murphy]

On Mon, Aug 1, 2016 at 9:26 AM, Chris Mason  wrote:
>
>
> On 07/23/2016 04:05 PM, Chris Murphy wrote:
>>
>> Using btrfs-debug-tree, I'm finding something a bit odd about some of
>> the items in this 39P file.
>>
>> Seems normal
>>
>> item 71 key (994163 EXTENT_DATA 43689967616) itemoff 12467 itemsize 53
>> extent data disk byte 617349906432 nr 80805888
>> extent data offset 0 nr 80805888 ram 80805888
>> extent compression(none)
>>
>> Seems not normal
>>
>> item 58 key (994163 EXTENT_DATA 38345535488) itemoff 13156 itemsize 53
>> extent data disk byte 0 nr 0
>> extent data offset 394752000 nr 61440 ram 34626881742770176
>> extent compression(none)
>>
>> There are quite a large number of items that take the 2nd form, and in
>> each case the ram value is the same as above.
>>
>>
>
> Can't really blame a bit flip for that one.  Looks like our hole truncation
> math has gone crazy there.  I'll see what I can find, but please yell if you
> can reproduce.

I've been trying, but no joy. Several bugs are required before hitting this.

User bug: I inadvertently edited the machine using virsh to use the
same backing qcow2 file for vda and vdb.
virsh bug: No warning for this double usage.
virt-manager bug: Starts the VM without warning when two virtio
devices are pointed to the same backing file.

Corruption of the file is inevitable. But exactly when it grew to 37P
I'm not sure, so far reproducing this results in a file limited to the
create time specified file size.


-- 
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: qcow2 becomes 37P in size while qemu crashes

[Chris Mason]

On 07/23/2016 04:05 PM, Chris Murphy wrote:

Using btrfs-debug-tree, I'm finding something a bit odd about some of
the items in this 39P file.

Seems normal

item 71 key (994163 EXTENT_DATA 43689967616) itemoff 12467 itemsize 53
extent data disk byte 617349906432 nr 80805888
extent data offset 0 nr 80805888 ram 80805888
extent compression(none)

Seems not normal

item 58 key (994163 EXTENT_DATA 38345535488) itemoff 13156 itemsize 53
extent data disk byte 0 nr 0
extent data offset 394752000 nr 61440 ram 34626881742770176
extent compression(none)

There are quite a large number of items that take the 2nd form, and in
each case the ram value is the same as above.




Can't really blame a bit flip for that one.  Looks like our hole 
truncation math has gone crazy there.  I'll see what I can find, but 
please yell if you can reproduce.


Thanks!

-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: qcow2 becomes 37P in size while qemu crashes

[Chris Murphy]

Kindof a rudimentary way of making a debug tree smaller, by filtering
by inode...

[root@f24m images]# btrfs-debug-tree -t 583 /dev/sda5 | grep -A 50 -B
50 994163 > inode994163_39PBfile.txt

381K gzip file
https://drive.google.com/open?id=0B_2Asp8DGjJ9Rk1qMG54MUNDWkE

But I'm going to rm this file so I can see if the problem is reproducible.

---

Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: qcow2 becomes 37P in size while qemu crashes

[Chris Murphy]

Using btrfs-debug-tree, I'm finding something a bit odd about some of
the items in this 39P file.

Seems normal

item 71 key (994163 EXTENT_DATA 43689967616) itemoff 12467 itemsize 53
extent data disk byte 617349906432 nr 80805888
extent data offset 0 nr 80805888 ram 80805888
extent compression(none)

Seems not normal

item 58 key (994163 EXTENT_DATA 38345535488) itemoff 13156 itemsize 53
extent data disk byte 0 nr 0
extent data offset 394752000 nr 61440 ram 34626881742770176
extent compression(none)

There are quite a large number of items that take the 2nd form, and in
each case the ram value is the same as above.


-- 
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html