[Qemu-devel] Stange problems with raw_co_get_block_status lseek path

[David Weber]

Hello,

I'm currently evaluating to switch our virtualization servers to a newer OS. 
This includes a switch from qemu 1.7 to 2.2 or 2.3. 
Our system heavily relies on big sparse images and drive_mirror. While testing, 
I experienced some problems with that combination.
The strange thing is, that everything works flawlessly on my workstation but 
fails on my servers.

Testcase:
# qemu-img create test 500G
# time qemu-img map test

Systems:
O3-3: Kubuntu 15.04 Workstation with stock-kernel 3.19.0-18-generic and stock 
qemu 2.2.0
Dinah: Ubuntu Server 15.04 with stock-kernel 3.19.0-18-generic and stock qemu 
2.2.0

Result on O3-3:
address@hidden:~# qemu-img create test 500G
Formatting 'test', fmt=raw size=536870912000 
address@hidden:~# time qemu-img map test
Offset          Length          Mapped to       File

real    0m0.049s
user    0m0.048s
sys     0m0.000s

Result on dinah:
address@hidden:~# qemu-img create test 500G
Formatting 'test', fmt=raw size=536870912000 
address@hidden:~# time qemu-img map test
Offset          Length          Mapped to       File
^C

real    0m41.862s
user    0m0.004s
sys     0m0.068s
(Stopped with ^C)

Strace on O3-3:
https://gist.github.com/anonymous/f221035e9176f7c71c74

Strace on dinah:
https://gist.github.com/anonymous/40b42888a65478c90b32

A git bisect between 1.7 and master revealed 
7c15903789953ead14a417882657d52dc0c19a24 "block/raw-posix: use seek_hole ahead 
of fiemap" as bad but this is not the real problem.
I also tried to switch from btrfs to ext4 but it didn't change anything.

At this point, I was pretty sure that was just stupit and missing something 
trivial.
I then startet a fedora 22 live system and I saw the same problem. It happens 
on both the ramdisk and a ext4 filesystem.

Any ideas on this? I'm pretty much stuck at this point. Please ask if you need 
more information.

Cheers,
David