linux-ext4 - Re: [Qemu-devel] Re-2: Strange problems with lseek in qemu-img map

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 5 Jun 2015 17:14:14 +0200 (CEST)
From:	Lukáš Czerner <lczerner@...hat.com>
To:	Stefan Hajnoczi <stefanha@...il.com>
cc:	David Weber <wb@...zinger.de>, qemu-devel@...gnu.org,
	linux-ext4@...r.kernel.org, wency@...fujitsu.com,
	wenqing.lz@...bao.com
Subject: Re: [Qemu-devel] Re-2:  Strange problems with lseek in qemu-img
 map

On Fri, 5 Jun 2015, Stefan Hajnoczi wrote:

> Date: Fri, 5 Jun 2015 15:05:15 +0100
> From: Stefan Hajnoczi <stefanha@...il.com>
> To: David Weber <wb@...zinger.de>
> Cc: qemu-devel@...gnu.org, linux-ext4@...r.kernel.org,
>     Lukas Czerner <lczerner@...hat.com>, wency@...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.

Regards,
-Lukas
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html