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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20161209012521.GM4326@dastard>
Date:   Fri, 9 Dec 2016 12:25:21 +1100
From:   Dave Chinner <david@...morbit.com>
To:     Andreas Dilger <adilger@...ger.ca>,
        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 Wed, Dec 07, 2016 at 07:34:17PM +0100, Sven Joachim 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.

The fallocate() call should be removed completely. Applications
should not be attempting to control file allocation like this as it
defeats all the optimisations that filesystems use to optimise IO
patterns and minimise filesystem fragmentation (e.g. delayed
allocation).

There is /rarely/ a need for applications to use fallocate() to
manage fragmentation - especailly as excessive use of fallocate()
actively harms performance and accelerates filesystem aging.

Unless an application has a specific, repeatable performance problem
due to file fragmentation, it should not be using fallocate() to
allocate file space.

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com
--
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