[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#838503: marked as done (debian-installer: mdadm should not start syncing RAID1 arrays at full speed during installation)

Your message dated Mon, 24 Dec 2018 13:49:32 +0000
with message-id <E1gbQbs-00076l-Ac@fasolo.debian.org>
and subject line Bug#838503: fixed in partman-md 89
has caused the Debian Bug report #838503,
regarding debian-installer: mdadm should not start syncing RAID1 arrays at full speed during installation
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
838503: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838503
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: debian-installer
Version: 20160630

When creating a RAID1 array in the debian-installer and using it for the
installation, mdadm immediately starts syncing the disks of the RAID
array.

This is a bad idea, because the subsequent install will be really slow on
rotational disks (linear disk access by mdadm and random disk access by
dpkg).  On a fairly recent computer with 2 SATA disks, the installation
took around 20 minutes before even arriving to the tasksel step.

I can see two solutions:

1) lower the speed of the syncing operation, by setting the
   "dev.raid.speed_limit_max" sysctl setting to e.g. 1000;

2) disable syncing altogether, by passing "--assume-clean" to mdadm when
   creating the array.


This second solution does not seem to be recommended by the mdadm
developers, here is an excerpt of the mdadm man page:

    --assume-clean

    Tell mdadm that the array pre-existed and is known to be clean.  It
    can be useful when trying to recover from a major failure as you can
    be sure that no data will be affected unless you actually write to the
    array.  It can also be used when creating a RAID1 or RAID10 if you
    want to avoid the initial resync, however this practice — while
    normally safe — is not recommended.  Use this only if you really know
    what you are doing.

    When the devices that will be part of a new array were filled with
    zeros before creation the operator knows the array is actually
    clean. If that is the case, such as after running badblocks, this
    argument can be used to tell mdadm the facts the operator knows.


Regards,

--- End Message ---
--- Begin Message --- 
Source: partman-md
Source-Version: 89

We believe that the bug you reported is fixed in the latest version of
partman-md, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 838503@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Holger Wansing <hwansing@mailbox.org> (supplier of updated partman-md package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Mon, 24 Dec 2018 14:24:27 +0100
Source: partman-md
Binary: partman-md
Architecture: source
Version: 89
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team <debian-boot@lists.debian.org>
Changed-By: Holger Wansing <hwansing@mailbox.org>
Description:
 partman-md - Add to partman support for MD (udeb)
Closes: 838503
Changes:
 partman-md (89) unstable; urgency=medium
 .
   * Team upload
 .
   [ Steve McIntyre ]
   * When we create a new RAID1/5/6/10 array , start it syncing at the
     minimum speed allowed by the system. If we let it run at full
     speed, that will just slow the installation down while we're
     installing packages etc. There's nothing to protect at this point
     anyway. Closes: #838503
 .
   [ Holger Wansing ]
   * Remove trailing whitespaces from changelog file, to fix lintian tag.
Checksums-Sha1:
 51185483f5b8e7542d4bcbb57a919396ae302272 1708 partman-md_89.dsc
 141574f698bd2c3d8976f3c3716b18f735ac675d 182088 partman-md_89.tar.xz
 f93181666366eaf2c39fba3d841a9f1961b7eea0 5267 partman-md_89_amd64.buildinfo
Checksums-Sha256:
 e6c8a298356a094730224d2c327df131f8551241cfa19cda268162bfbfcb9f4a 1708 partman-md_89.dsc
 de5925c525b84f355c4826f19a03d79988457735289e95ab46dfcb02246ffb42 182088 partman-md_89.tar.xz
 bc8128c1d3c9305c525dddae7ba261bd6dcb1a5dbed00c0ca73a921c44dfcec6 5267 partman-md_89_amd64.buildinfo
Files:
 d4ff1b4d7f0b88286a441cb554715981 1708 debian-installer standard partman-md_89.dsc
 bda0f6339b205e512a48c99f6c5ea3ef 182088 debian-installer standard partman-md_89.tar.xz
 3a2cc47b4f5ebafa030ef32d4307fa95 5267 debian-installer standard partman-md_89_amd64.buildinfo

-----BEGIN PGP SIGNATURE-----

iQJJBAEBCAAzFiEESWrG6BRCSzSFCDUpWfGHyhVusHYFAlwg30sVHGh3YW5zaW5n
QG1haWxib3gub3JnAAoJEFnxh8oVbrB2afMP/j+bECmGLsOEjArPn4isZq7DBzuH
X1Gq1JqT6+4oNhMZEEw3Oa9aehN3J0zn32OTig5qXI8rot3cRVk6nvUDL3nFfwT3
rW80f744BOYhR1bK4L6WmBtWwPyp1igDB0Yc2kRVE2Rw73ladmrw3Iah1tMSeL+D
JsT8SP99DH/QR8kwh15q1sSGOPqiZncwwmYoGHmX9vt1hau8sp9Bhsba8O+WLsVu
HYVQ59oCViU0bM4BGqLnpRRgCqe6N08riamw8EMU55GJ4iavnp44/waA1GjwId8Q
Ic+wDglSDFl1EcfsOBGynAZOguVe27E2Nu4mFkzoHhBxv8OWm43R7MshuyKqBnfd
PKh8dB1M1rnLS9TYbYH41Quo3U9LdWauthqyMTP2RIWKmZOuU23hT22o6bsf0gNU
vctla8SWVimU2aulaZ4yzilR5xire2/iMpW7gl6+YHJF3MNdb9EE2kktjYahMrGi
T/lbJt8HSBZwJ4YAECunKBKxHaCWkMlbyVQu1xEOCjWRQH4mU+5euBzH9dNuugWT
KWjYt9JR376ZRYCLfCvqikh3o7X2T0edxQBYJCD+QTblvgO2PrGPfzqc2EpObMFr
8Vb77FCkGOUYeTO64MqaMdKAzwxAulIGMTLFvZECQgs+g0roVMq5zrd1EIcAUn+b
xRJoh1ZAUtUphFiV
=yqnx
-----END PGP SIGNATURE-----

--- End Message ---
Reply to: