On Tue, Jun 02, 2015 at 02:54:17PM +0200, David Weber wrote: > 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
These systems have the same kernel but for some reason O3-3 completes quickly while Dinah takes a long time in lseek(fd, offset, SEEK_DATA). It looks like the file is empty (the syscall keeps returning ENXIO because there are no allocated blocks in the file where qemu-img probes). > Result on O3-3: > root@o3-3:~# qemu-img create test 500G > Formatting 'test', fmt=raw size=536870912000 > root@o3-3:~# time qemu-img map test > Offset Length Mapped to File > > real 0m0.049s > user 0m0.048s > sys 0m0.000s > > Result on dinah: > root@dinah:~# qemu-img create test 500G > Formatting 'test', fmt=raw size=536870912000 > root@dinah:~# 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. "it" == qemu-img map hangs or takes a very long time? Can you post a shell script that reproduces this with a ramdisk? That seems like the easiest way to get people debugging it. Stefan
pgpHP2232slld.pgp
Description: PGP signature
