From owner-freebsd-geom@FreeBSD.ORG Tue Dec 19 01:55:10 2006 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 A6D8516A407; Tue, 19 Dec 2006 01:55:10 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8230143CB8; Tue, 19 Dec 2006 01:55:03 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.66.55.136] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1GwTyk2giz-0007Wz; Tue, 19 Dec 2006 02:41:15 +0100 From: Max Laier Organization: FreeBSD To: Pawel Jakub Dawidek Date: Tue, 19 Dec 2006 02:41:05 +0100 User-Agent: KMail/1.9.4 References: <200612161537.21348.max@love2party.net> <20061216170910.GC10541@garage.freebsd.pl> In-Reply-To: <20061216170910.GC10541@garage.freebsd.pl> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1325855.hogl3VlRi7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200612190241.13265.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Poul-Henning Kamp , freebsd-geom@freebsd.org Subject: Re: gmirror comes up DEGRADED 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, 19 Dec 2006 01:55:10 -0000 --nextPart1325855.hogl3VlRi7 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 16 December 2006 18:09, Pawel Jakub Dawidek wrote: > On Sat, Dec 16, 2006 at 03:37:15PM +0100, Max Laier wrote: > > Hi, > > > > I'm new to really playing with gmirror and friends, so please forgive > > me if this is a FAQ - my searches didn't turn up anything. Please CC > > me, for I'm not on the list. > > > > Following setup: 6.2-pre as of Wednesday > > > > ad0, ad2 250G ata on > > atapci0@pci0:31:1: class=3D0x010180 card=3D0x80281043 chip=3D0x244b80= 86 > > rev=3D0x05 hdr=3D0x00 > > vendor =3D 'Intel Corporation' > > device =3D '82801BA (ICH2) UltraATA/100 IDE Controller' > > class =3D mass storage > > subclass =3D ATA > > > > mirror/gm0 over ad0, ad2 > > > > mirror/gm0s1 spanning all of the available space on gm0 > > mirror/gm0s1a spanning all of the available space on gm0s1 > > > > mirror/gm0s1a.bde gbde encryption on gm0s1a.bde > > > > Now if I wait for the mirror to get in sync and do a reboot, it comes > > up DEGRADED and resyncs ad0 (again) :-\ Does that mean I have to > > stop everything manually before rebooting? Is there a fundamental > > error in the setup that I can remedy? How do you do this right? It > > certainly is not a good idea to do it the other way round (i.e. > > mirror two gbde provider), right? > > > > Any help greatly appreciated. > > If I read the code properly, the problem you are seeing is because gbde > doesn't close its consumers on shutdown. It opens consumer r1w1e1 on > attach, but it only close it on manual detach. This is wrong. It should > open consumer on first provider open or should close it on shutdown. I > decided not to touch gbde, so you need to ask phk@ or someone else to > fix it. Would it make sense to have a "graceful orphanization" for this kind of=20 things? i.e. an operation with a semantic like "somebody asked me to go=20 away, so next time you get the chance - could you do so as well (for I=20 depend on you being okay with this)?" It seems overly complicated to ask=20 classes that don't require a state save to implement a dedicated hook to=20 go away on system shutdown. For a "graceful orphanization", however, all=20 you need to do is keep a flag in the softc, pass down the request and=20 wait for the open count to drop to zero. Does that sound like it might work? I'd try to dig into it if it makes=20 sense. > I also found a bug in g_bde_access() function: > > if ((cp->acr + dr) =3D=3D 0 && (cp->acw + dw) =3D=3D 0 && (cp->ace + de)= =3D=3D 1) > { > > I think it should be: > > if ((cp->acr + dr) =3D=3D 1 && (cp->acw + dw) =3D=3D 0 && (cp->ace + de)= =3D=3D 1) > { Since *dr is decremented in the body, this seems to be the case indeed. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1325855.hogl3VlRi7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBFh0M5XyyEoT62BG0RAjieAJ9QYCuLNvIEcZZI/vy6qnUpQ4AmJgCfVeFr KlIEe+TVG95PMc4gk1OSzRI= =NXU+ -----END PGP SIGNATURE----- --nextPart1325855.hogl3VlRi7--