From owner-freebsd-stable@FreeBSD.ORG Sat Sep 9 19:43:07 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B002D16A412 for ; Sat, 9 Sep 2006 19:43:07 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00D7443D46 for ; Sat, 9 Sep 2006 19:43:06 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 776AA48A29; Sat, 9 Sep 2006 21:43:04 +0200 (CEST) Received: from localhost (public-gprs3449.centertel.pl [87.96.13.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id D663F48A26; Sat, 9 Sep 2006 21:42:50 +0200 (CEST) Date: Sat, 9 Sep 2006 21:42:30 +0200 From: Pawel Jakub Dawidek To: Volker Message-ID: <20060909194230.GA85109@garage.freebsd.pl> References: <44FF4909.9020108@vwsoft.com> <44FF5B02.3090804@vwsoft.com> <44FF6FE6.4080602@protected-networks.net> <4500860B.3050804@protected-networks.net> <450089E2.5090906@vwsoft.com> <4502CF2C.6000104@vwsoft.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: <4502CF2C.6000104@vwsoft.com> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-stable@freebsd.org Subject: Re: gmirror RAID-1: rebuilding freezes machine X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2006 19:43:07 -0000 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 09, 2006 at 04:26:52PM +0200, Volker wrote: > One feature request on gmirror: >=20 > If a system comes up and more than one mirror is out of sync, > currently gmirror tries (in automatic mode) to re-sync all providers > at the same time which slows down the system. >=20 > When gmirror tries to do a resync, it would make sense to do that > one by one and not all at the same time as the disk head moves > erratically and seek time is wasted time. Because of that I'm now > using automatic rebuild mode on the first (root-fs) gmirror slice > and will fire a manual re-sync on the others one by one if needed. I > guess I'll put that logic in an rc script but gmirror might avoid > doing concurrent re-syncs and instead using a queue like behavior. This is quite complex issue to solve: - If you have 8 disks in your server, every two are in mirror configuration, you do want to synchronize all the mirrors in parallel. - If you have 2 disks and 4 mirrors configured on partitions from those disks, you want to synchronize them one by one. - If you have UFS file system on a mirror provider, you want to delay synchronization or delay fsck, but don't want them to run together. - Hmm, maybe you have also raid3 configured on the same disks you have mirrors? Basically every mirror is a separate entity and doesn't have any knowledge about the rest of mirrors (or any other GEOM classes). Keeping it that way is a good thing, IMHO. Another thing is that GEOM as an infrastructure doesn't want me to treat some providers as special, ie. I shouldn't care if mirror is configured on plain disks or on partitions. And maybe one component is a disk and one is a partition (it could be useful when one has disks of different sizes). Taking all of this into account, I don't think such logic should be implemented in gmirror itself. I do agree that we should provide some userland (rcNG? daemon?) infrastructure to allow to easly configure order of gmirror synchronization, graid3 synchronization, fsck, gvinum synchronization(?), etc. For example we have those providers: mirror/foo1 (ad0s1 ad1s1) mirror/foo2 (ad0s2 ad1s2) mirror/foo3 (ad0s3 ad1s3) mirror/bar (ad2s1 ad3s1) raid3/baz (ad0s4 ad1s4 ad2s2) We have a daemon (shell script?) runing heavy disk tasks in the given order: fsck:mirror/foo1 fsck:mirror/bar fsck:mirror/foo2 (after fsck:mirror/foo1) fsck:mirror/foo3 (after fsck:mirror/foo2) fsck:raid3/baz (after fsck:mirror/foo2,fsck:mirror/bar) sync:mirror/foo1 (after fsck:raid3/baz) sync:mirror/bar (after fsck:raid3/baz) sync:mirror/foo2 (after sync:mirror/foo1) sync:mirror/foo3 (after sync:mirror/foo2) sync:raid3/baz (after sync:mirror/foo2,sync:mirror/bar) I hope this is easy. I'm also planning to implement some messages which will be passed via devd(8), like 'component X disconnected from Y', 'synchronization of component X in Y finished', etc. which could be helpful for such a daemon. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFFAxkmForvXbEpPzQRApkQAJ9SA6cJ3tucbQAw+K5yj32XkyfK+gCeKc4a 7o/3JWTFzUgCGxHC3GglQT8= =Dzlu -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH--