From owner-freebsd-geom@FreeBSD.ORG Tue Feb 13 15:02:17 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4FA4416A46B for ; Tue, 13 Feb 2007 15:02:17 +0000 (UTC) (envelope-from myself@rojer.pp.ru) Received: from wooster.rojer.pp.ru (wooster.rojer.pp.ru [80.68.246.188]) by mx1.freebsd.org (Postfix) with ESMTP id 0B57F13C4AA for ; Tue, 13 Feb 2007 15:02:17 +0000 (UTC) (envelope-from myself@rojer.pp.ru) Received: from wooster.rojer.pp.ru (localhost [127.0.0.1]) by wooster.rojer.pp.ru (Postfix) with ESMTP id 397E7114CB; Tue, 13 Feb 2007 17:38:48 +0300 (MSK) X-Spam-Checker-Version: SpamAssassin 3.1.7-rojer (2006-10-05) on wooster.rojer.pp.ru X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.7-rojer Received: from [IPv6:::1] (localhost [127.0.0.1]) by wooster.rojer.pp.ru (Postfix) with ESMTP; Tue, 13 Feb 2007 17:38:39 +0300 (MSK) Message-ID: <45D1CD24.1090000@rojer.pp.ru> Date: Tue, 13 Feb 2007 14:37:24 +0000 From: Deomid Ryabkov User-Agent: Thunderbird 1.5.0.9 (X11/20070211) MIME-Version: 1.0 To: "R. B. Riddick" References: <359629.81860.qm@web30308.mail.mud.yahoo.com> In-Reply-To: <359629.81860.qm@web30308.mail.mud.yahoo.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Christian Laursen , freebsd-geom@freebsd.org Subject: Re: geom_mirror delayed synchronizing question X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2007 15:02:17 -0000 R. B. Riddick wrote: > I would be glad if it was possible for gmirror to detect an idle > gmirror-device... If it is idle, requests r issued more frequent and if the > device experiences concurrent requests (e. g. from fsck), gmirror does no or > hardly any sync requests... > i had somewhat different idea of making a kind-of lazy resync but with bounded time to recovery. the thing is that on a busy system there's a lot of i/o going on, so we can piggy-back our recovery on that. e.g., as we read blocks, we copy them to the out-of-sync components. the way we bound our recovery time is we say, ok, i want the mirror synced in X hours (a sysctl) and we then keep track of how many blocks our lazy resync yields. for example, each minute we evaluate how many blocks we have resynced lazily and, with the target time of recovery, how many we are missing. we then schedule the difference to be resynced (e.g., with N blocks and X hours of target resync time, we should resync N/X/60 blocks every minute, so if lazy resync does not resync enough blocks, we read and resync them directly). the drawback is that this would necessitate keeping a bitmap of resynced blocks, but the size is manageable with blocks of, say, 64k. the map can be discarded when resync is complete. > But this strategy could lead to a very very lengthly rebuild process on a very > busy server, which contracts a RAID0-like risk of (complete) device failure... > > Maybe this "nice feature" should be implemented somehow intelligently? Maybe > phases of rebuild and phases where concurrent user-land requests r executed? > E. g.: 10 second undisturbed user-land (if there r any pending requests) and > then 1 second gmirror's rebuild requests... > might work as well. again, these numbers can be calculated from the target resync time. -- Deomid Ryabkov aka Rojer myself@rojer.pp.ru rojer@sysadmins.ru ICQ: 8025844