From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-15?Q?Luk=E1=A8_Czerner?= Subject: Re: Re-2: Strange problems with lseek in qemu-img map Date: Tue, 9 Jun 2015 12:35:15 +0200 (CEST) Message-ID: References: <00056481.556F34D3@pegasus.munzinger.de> <20150605140515.GB30104@stefanha-thinkpad.redhat.com> <55726ECE.70101@gmail.com> Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-1659545805-1433846122=:26548" Cc: David Weber , Stefan Hajnoczi , linux-ext4@vger.kernel.org, qemu-devel@nongnu.org, wenqing.lz@taobao.com To: Wen Congyang Return-path: In-Reply-To: <55726ECE.70101@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: linux-ext4.vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-1659545805-1433846122=:26548 Content-Type: TEXT/PLAIN; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sat, 6 Jun 2015, Wen Congyang wrote: > Date: Sat, 06 Jun 2015 11:53:50 +0800 > From: Wen Congyang > To: Luk=E1=9A Czerner , Stefan Hajnoczi > Cc: David Weber , 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 >=20 > At 2015/6/5 23:14, Luk=E1=9A Czerner Wrote: > > On Fri, 5 Jun 2015, Stefan Hajnoczi wrote: > >=20 > > > Date: Fri, 5 Jun 2015 15:05:15 +0100 > > > From: Stefan Hajnoczi > > > To: David Weber > > > Cc: qemu-devel@nongnu.org, linux-ext4@vger.kernel.org, > > > Lukas Czerner , wency@cn.fujitsu.com > > > Subject: Re: [Qemu-devel] Re-2: Strange problems with lseek in qem= u-img > > > map > > >=20 > > > 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 pro= blem. > > > > > > It > > > > > > happens > > > > > > on both the ramdisk and a ext4 filesystem. > > > > >=20 > > > > > "it" =3D=3D 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. > > > >=20 > > > > >=20 > > > > > Can you post a shell script that reproduces this with a ramdisk= ? That > > > > > seems like the easiest way to get people debugging it. > > > >=20 > > > > You can use the following commands. > > > >=20 > > > > 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 > > > >=20 > > > > This takes foreover on all my systems. > > >=20 > > > I experience the same thing on Linux 4.1.0-rc5 with ext4 (4 KB file > > > system block size, 512B device sector size). > > >=20 > > > The lseek() calls take *seconds* to complete on a completely empty > > > (sparse) 500G file. > > >=20 > > > Here is the perf-top(1) output: > > >=20 > > > 34.08% [kernel] [k] _raw_read_lock > > > 21.11% [kernel] [k] ext4_es_lookup_exte= nt > > > 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 > > >=20 > > > Yikes! > > >=20 > > > The syscall causing this is just: > > >=20 > > > lseek(7, 0, SEEK_DATA) > > >=20 > > > Lukas: I've CCed you because you have helped with ext4 issues in th= e > > > past. Not sure if you have time or if this is your area. > > >=20 > > > Stefan > >=20 > > Hi, > >=20 > > this is definitely an issue with extent status tree and I have not se= en > > 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. >=20 > 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=3D14516bb7bb6ffbd49f35389f9ece3b2045ba5815 >=20 > But this patch introduced another problem, and have been reverted. >=20 > Thanks > Wen Congyang Wow, the code is so broken :) Luckily the fix should be fairly easy, I am testing it now. Thanks everyone for pointing this out. -Lukas >=20 > >=20 > > Regards, > > -Lukas > >=20 > >=20 --8323328-1659545805-1433846122=:26548--