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]
Message-Id: <18255D8F-F475-44F0-81C3-5E86AE1E554C@dilger.ca>
Date:   Wed, 7 Dec 2016 13:14:22 -0700
From:   Andreas Dilger <adilger@...ger.ca>
To:     Sven Joachim <svenjoac@....de>
Cc:     Renaud Mariana <rmariana@...ine.net>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>,
        debian-dpkg@...ts.debian.org
Subject: Re: HUGE slowdown when doing dpkg with ext4 over nbd

On Dec 7, 2016, at 11:34 AM, Sven Joachim <svenjoac@....de> wrote:
> 
> On 2016-12-07 11:16 -0700, Andreas Dilger wrote:
> 
>> Add debian-dpkg mailing list to CC.
>> 
>> On Dec 7, 2016, at 10:58 AM, Andreas Dilger <adilger@...ger.ca> wrote:
>>> 
>>> On Dec 7, 2016, at 2:52 AM, Renaud Mariana <rmariana@...ine.net> wrote:
>>>> 
>>>> Here are my answers, hope it will help solve this issue, thanks.
>>>> 
>>>> Recap:
>>>> dpkg kibana on ext4 over a nbd device takes 10 minutes
>>>> with xfs it's only 30s.
>>>> with ext4 no extends only 30s.
>>>> 
>>>> 
>>>> kernels :
>>>> 4.5.7 has this issue as older kernel like 4.4.34
>>>> The issue is also when nbd client & server run on same host
>>>> 
>>>> 
>>>> How small are the files?
>>>> here is the histogram of file sizes : http://pasteboard.co/6HC3nKyk2.png
>>>> We can see 5000 files around 512 Bytes.
>>> 
>>> Definitely there is no value to use fallocate for 512-byte files, or any
>>> of the files that can be written in a single write() syscall.  I'd expect
>>> any reasonable tool to be using a write buffer of at least 2-4MB these
>>> days to get good performance, so writes below the buffer size shouldn't
>>> use fallocate() at all.
> 
> It should be noted that the latest dpkg (1.18.15) only uses fallocate
> for files which are at least 16 KiB in size[1], so it would be nice if
> Renaud could recheck with that version, or cherry-pick the patch into
> whatever version he uses.

Any particular reason you chose 16KB for the fallocate() limit?  If the
write() is being submitted in a single call and isn't outrageously large
(i.e. over tens of MB), then there isn't any real benefit from fallocate()
since ext4, XFS, btrfs will already do delayed block allocation based on
the file size size so it will always get a contiguous allocation on disk
if there is free space available.  I'm assuming that you aren't doing
sync writes when extracting the files from the .deb?

My recommendation would be to avoid fallocate() until the file size is
larger than 1MB or more (ext4 will automatically preallocate up to 8MB
actually, but not sure about other filesystems).  I was trying to look
through the dpkg code to see what buffer sizes are used for writes, but
that was not very easy to find.

> 1. https://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/?id=a971ad91437af8880cad4703695dcf12ee45959b


Cheers, Andreas






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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ