Hi! Guillem Jover <guil...@debian.org> wrote: > Control: tags -1 moreinfo > > Hi! > > On Wed, 2016-05-18 at 10:44:34 +0200, Dr. Johann Pfefferl wrote: > > Package: dpkg > > Version: 1.17.26 > > Severity: important > > > * What led up to the situation? > > > > Installation of a system takes an extreme long time. The systems have > > RAID controllers included: > > > > - Serial Attached SCSI controller: LSI Logic / Symbios Logic SAS2008 > > PCI-Express Fusion-MPT SAS-2 > > - Serial Attached SCSI controller: Intel Corporation C606 chipset Dual > > 4-Port SATA/SAS Storage Control Unit > > > > Classic SATA harddisks are connected to the IO controllers. > > > > Normally an install takes 10 minutes. On these systems it takes 50 > > minutes. > > Hmmm, I don't see why the hardware used there should in principle > affect this but let's see. > > > * Analysis > > > > By bisecting the source code of "dpkg" package with git showed that > > commit 87b0b20b86407baf1deb4e91b3fd839e01228ac8 > > > > commit 87b0b20b86407baf1deb4e91b3fd839e01228ac8 > > Author: Guillem Jover <guil...@debian.org> > > Date: Tue Jul 15 21:00:52 2014 +0200 > > > > dpkg: Try to preallocate the disk size for extracted files > > > > This might help in avoiding filesystem fragmentation, and possibly > > improve performance on some filesystems. > > > > We use the system specific methods if available, and only use > > posix_fallocate() if nothing else is available, because on some > > systems > > its semantics are counter to what we want to obtain here, as the > > libc > > library will fallback to manually writing '\0' to each block to > > force > > the preallocation, instead of just failing and leaving the > > application > > to do so if desired. > > > > introduced the massive slow down of the install process. > > > > After "git revert" of this commit the installation behaved as expected. > > > > So the problematic system call on these systems is "fallocate". > > Thanks for tracking this down! What filesystem did you use there? In > case it's not ext3/4 and you can try another reinstall using another > filesystem to see if it helps, would be appreciated, because that would > hint at a problem in the filesystem in the kernel. >
We have tracked down the problem to be caused by the ext4 filesystem. If we mount the install directory via mount -o dioread_nolock,data=writeback,barrier=0,commit=60 ... the installation process is fast. Ftrace showed that the delay is caused by sb_issue_zeroout() in ext4_ext_zeroout() called by ext4_ext_convert_to_initialized(). This call chain is initially triggered by fallocate(). As explained in https://bugzilla.kernel.org/show_bug.cgi?id=56821 this can be disabled using the max_zeroout parameter. echo 0 > /sys/fs/ext4/sdb2/extent_max_zeroout_kb > Thanks, > Guillem -- Siemens AG Corporate Technology Research & Technology Center CT RDA ITP SES-DE Otto-Hahn-Ring 6 81739 Muenchen, Germany mailto: johann.pfeff...@siemens.com phone: +49 89 636 634 021 fax: +49 89 636 33045 _____________________________________________________ SIEMENS AG: Vorsitzender des Aufsichtsrats: Gerhard Cromme Vorstand: Joe Kaeser, Vorsitzender Roland Busch, Klaus Helmrich, Hermann Requardt, Siegfried Russwurm, Michael Süß, Ralf P. Thomas Sitz der Gesellschaft: Berlin und München, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684 WEEE-Reg.-Nr. DE 23691322
