On Mon, Aug 1, 2016 at 9:26 AM, Chris Mason <c...@fb.com> 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
