From: Wen Congyang <ghostwcy@gmail.com>
To: "Lukáš Czerner" <lczerner@redhat.com>,
"Stefan Hajnoczi" <stefanha@gmail.com>
Cc: David Weber <wb@munzinger.de>,
linux-ext4@vger.kernel.org, qemu-devel@nongnu.org,
wenqing.lz@taobao.com
Subject: Re: Re-2: Strange problems with lseek in qemu-img map
Date: Sat, 06 Jun 2015 11:53:50 +0800 [thread overview]
Message-ID: <55726ECE.70101@gmail.com> (raw)
In-Reply-To: <alpine.LFD.2.00.1506051711390.13926@localhost.localdomain>
At 2015/6/5 23:14, Lukáš Czerner Wrote:
> On Fri, 5 Jun 2015, Stefan Hajnoczi wrote:
>
>> Date: Fri, 5 Jun 2015 15:05:15 +0100
>> From: Stefan Hajnoczi <stefanha@gmail.com>
>> To: David Weber <wb@munzinger.de>
>> Cc: qemu-devel@nongnu.org, linux-ext4@vger.kernel.org,
>> Lukas Czerner <lczerner@redhat.com>, wency@cn.fujitsu.com
>> Subject: Re: [Qemu-devel] Re-2: Strange problems with lseek in qemu-img map
>>
>> On Wed, Jun 03, 2015 at 03:09:40PM +0000, David Weber wrote:
>>>>> 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?
>>> I never waited for it to complete but I guess it just takes very long.
>>>
>>>>
>>>> Can you post a shell script that reproduces this with a ramdisk? That
>>>> seems like the easiest way to get people debugging it.
>>>
>>> You can use the following commands.
>>>
>>> mkfs.ext4 /dev/ram0
>>> mkdir -p /mnt/tmp
>>> mount /dev/ram0 /mnt/tmp
>>> cd /mnt/tmp
>>> qemu-img create test 500G
>>> time qemu-img map test
>>>
>>> This takes foreover on all my systems.
>>
>> I experience the same thing on Linux 4.1.0-rc5 with ext4 (4 KB file
>> system block size, 512B device sector size).
>>
>> The lseek() calls take *seconds* to complete on a completely empty
>> (sparse) 500G file.
>>
>> Here is the perf-top(1) output:
>>
>> 34.08% [kernel] [k] _raw_read_lock
>> 21.11% [kernel] [k] ext4_es_lookup_extent
>> 20.67% [kernel] [k] ext4_es_find_delayed_extent_range
>> 8.68% [kernel] [k] ext4_map_blocks
>> 4.99% [kernel] [k] ext4_llseek
>> 1.90% [kernel] [k] rb_next
>> 0.14% [kernel] [k] __fget
>>
>> Yikes!
>>
>> The syscall causing this is just:
>>
>> lseek(7, 0, SEEK_DATA)
>>
>> Lukas: I've CCed you because you have helped with ext4 issues in the
>> past. Not sure if you have time or if this is your area.
>>
>> Stefan
>
> Hi,
>
> this is definitely an issue with extent status tree and I have not seen
> it before. I'll look at it first thing next week, but meanwhile I'll
> add Zheng Liu who is the author of the extent status tree so he
> might be able to help you.
It is an known bug, and Dmitry Monakhov tried to fix it:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=14516bb7bb6ffbd49f35389f9ece3b2045ba5815
But this patch introduced another problem, and have been reverted.
Thanks
Wen Congyang
>
> Regards,
> -Lukas
>
>
WARNING: multiple messages have this Message-ID (diff)
From: Wen Congyang <ghostwcy@gmail.com>
To: "Lukáš Czerner" <lczerner@redhat.com>,
"Stefan Hajnoczi" <stefanha@gmail.com>
Cc: David Weber <wb@munzinger.de>,
linux-ext4@vger.kernel.org, qemu-devel@nongnu.org,
wenqing.lz@taobao.com
Subject: Re: [Qemu-devel] Re-2: Strange problems with lseek in qemu-img map
Date: Sat, 06 Jun 2015 11:53:50 +0800 [thread overview]
Message-ID: <55726ECE.70101@gmail.com> (raw)
In-Reply-To: <alpine.LFD.2.00.1506051711390.13926@localhost.localdomain>
At 2015/6/5 23:14, Lukáš Czerner Wrote:
> On Fri, 5 Jun 2015, Stefan Hajnoczi wrote:
>
>> Date: Fri, 5 Jun 2015 15:05:15 +0100
>> From: Stefan Hajnoczi <stefanha@gmail.com>
>> To: David Weber <wb@munzinger.de>
>> Cc: qemu-devel@nongnu.org, linux-ext4@vger.kernel.org,
>> Lukas Czerner <lczerner@redhat.com>, wency@cn.fujitsu.com
>> Subject: Re: [Qemu-devel] Re-2: Strange problems with lseek in qemu-img map
>>
>> On Wed, Jun 03, 2015 at 03:09:40PM +0000, David Weber wrote:
>>>>> 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?
>>> I never waited for it to complete but I guess it just takes very long.
>>>
>>>>
>>>> Can you post a shell script that reproduces this with a ramdisk? That
>>>> seems like the easiest way to get people debugging it.
>>>
>>> You can use the following commands.
>>>
>>> mkfs.ext4 /dev/ram0
>>> mkdir -p /mnt/tmp
>>> mount /dev/ram0 /mnt/tmp
>>> cd /mnt/tmp
>>> qemu-img create test 500G
>>> time qemu-img map test
>>>
>>> This takes foreover on all my systems.
>>
>> I experience the same thing on Linux 4.1.0-rc5 with ext4 (4 KB file
>> system block size, 512B device sector size).
>>
>> The lseek() calls take *seconds* to complete on a completely empty
>> (sparse) 500G file.
>>
>> Here is the perf-top(1) output:
>>
>> 34.08% [kernel] [k] _raw_read_lock
>> 21.11% [kernel] [k] ext4_es_lookup_extent
>> 20.67% [kernel] [k] ext4_es_find_delayed_extent_range
>> 8.68% [kernel] [k] ext4_map_blocks
>> 4.99% [kernel] [k] ext4_llseek
>> 1.90% [kernel] [k] rb_next
>> 0.14% [kernel] [k] __fget
>>
>> Yikes!
>>
>> The syscall causing this is just:
>>
>> lseek(7, 0, SEEK_DATA)
>>
>> Lukas: I've CCed you because you have helped with ext4 issues in the
>> past. Not sure if you have time or if this is your area.
>>
>> Stefan
>
> Hi,
>
> this is definitely an issue with extent status tree and I have not seen
> it before. I'll look at it first thing next week, but meanwhile I'll
> add Zheng Liu who is the author of the extent status tree so he
> might be able to help you.
It is an known bug, and Dmitry Monakhov tried to fix it:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=14516bb7bb6ffbd49f35389f9ece3b2045ba5815
But this patch introduced another problem, and have been reverted.
Thanks
Wen Congyang
>
> Regards,
> -Lukas
>
>
next prev parent reply other threads:[~2015-06-06 3:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-03 15:09 [Qemu-devel] Re-2: Strange problems with lseek in qemu-img map David Weber
2015-06-05 14:05 ` Stefan Hajnoczi
2015-06-05 14:05 ` [Qemu-devel] " Stefan Hajnoczi
2015-06-05 15:14 ` Lukáš Czerner
2015-06-05 15:14 ` Lukáš Czerner
2015-06-06 3:53 ` Wen Congyang [this message]
2015-06-06 3:53 ` Wen Congyang
2015-06-09 10:35 ` Lukáš Czerner
2015-06-09 10:35 ` [Qemu-devel] " Lukáš Czerner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55726ECE.70101@gmail.com \
--to=ghostwcy@gmail.com \
--cc=lczerner@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=wb@munzinger.de \
--cc=wenqing.lz@taobao.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.