linux-ext4 - Re: HUGE slowdown when doing dpkg with ext4 over nbd

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-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <78AEFE7B-685B-4B4E-A15E-E3F6D99DD343@dilger.ca>
Date:   Tue, 6 Dec 2016 11:45:16 -0700
From:   Andreas Dilger <adilger@...ger.ca>
To:     Renaud Mariana <rmariana@...ine.net>
Cc:     linux-ext4@...r.kernel.org
Subject: Re: HUGE slowdown when doing dpkg with ext4 over nbd

On Dec 6, 2016, at 6:13 AM, Renaud Mariana <rmariana@...ine.net> wrote:
> 
> Hello,
> 
> We have noticed a HUGE slowdown when doing dpkg with ext4 over nbd (qemu-nbd as a server)
> 
> dpkg times with default mkfs & mount options is :
> 
> - ext4: 10 mn
> - xfs : 30s.
> 
> Disabling extents :
> mkfs.ext4 -O ^extent
> fixed the pb that is ext4 is as fast as xfs.
> 
> Any ideas ?

Is dpkg using fallocate() (uninitialized extents)?  Could you strace the dpkg
process with -fff to catch forked processes and search for fallocate() calls.

fallocate() is the only thing I can think of that would make extents slower
than block-mapped files.

> Details :
> 
> xnbd-client  --blocksize 4096  qemu-nbd-ip 10000 /dev/nbd0
> mkfs.ext4 /dev/nbd0
> mount /dev/nbd0 /newroot
> 
> wget https://download.elastic.co/kibana/kibana/kibana-4.6.1-amd64.deb
> time dpkg -i kibana-4.6.1-amd64.deb

What kernel version are you currently running?

Is this problem new with this kernel (i.e. it worked fine with older kernels?

> kibana installs many small files (23209 entries) under /opt/kibana

How small are the files?

Cheers, Andreas




Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)