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 for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150605140515.GB30104@stefanha-thinkpad.redhat.com>
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

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ