From owner-freebsd-current@FreeBSD.ORG Wed Oct 5 23:15:17 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61227106564A; Wed, 5 Oct 2011 23:15:17 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate.funkthat.com [70.36.235.232]) by mx1.freebsd.org (Postfix) with ESMTP id 030CC8FC1E; Wed, 5 Oct 2011 23:15:16 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id p95Mrra9039436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Oct 2011 15:53:53 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id p95MrrHh039435; Wed, 5 Oct 2011 15:53:53 -0700 (PDT) (envelope-from jmg) Date: Wed, 5 Oct 2011 15:53:53 -0700 From: John-Mark Gurney To: Lev Serebryakov Message-ID: <20111005225353.GG14645@funkthat.com> Mail-Followup-To: Lev Serebryakov , "Andrey V. Elsukov" , current@freebsd.org, freebsd-geom@freebsd.org References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8BE604.7090803@yandex.ru> <1822051193.20111005102710@serebryakov.spb.ru> <1239869336.20111005103945@serebryakov.spb.ru> <4E8C0C88.7000702@yandex.ru> <813229977.20111005125104@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <813229977.20111005125104@serebryakov.spb.ru> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 05 Oct 2011 15:53:53 -0700 (PDT) Cc: "Andrey V. Elsukov" , current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 23:15:17 -0000 Lev Serebryakov wrote this message on Wed, Oct 05, 2011 at 12:51 +0400: > Hello, Andrey. > You wrote 5 ??????? 2011 ?., 11:51:36: > > > On 05.10.2011 10:39, Lev Serebryakov wrote: > >>> (1) Class and name of GEOM which is affected. > >>> (2) Name of provider which is affected. > >>> (3) Name of underlying provider which is lost (consumer from > >>> reporting GEOM's point of view). > >>> (4) Resulting state of affected provider (fixable, alive, dead). > > > All except last could be get from the consumer in the orphan method. > I'm afraid, that (2) could not be known too in generic way, as GEOM > could have several providers, and only part of them could be affected by > disconnection. Consumer contains geom (with class) and underlying > provider, it is items (1) and (3)... > > >> Other example -- geom_label creates and destroys about 10 labels on > >> boot (on my test VM) and, if DESTROYED will be reported by very > >> generic mechanism, it will end up with 10 e-mails to administrator on > >> every boot -- I've got this, when put notifications in too generic > >> place for first try. > > Ok, good point. Can you explain how your script will distinguish which > > actions are performed by administrator? Since change made by administrator > > could trigger disappearing of several child geoms. > Not the script, but GEOMs themselves. They knows, why disk > disappears. Of course, it work only one-level -- if administrator > calls "gmirror remove gm0 ada4" geom_mirror knows, that ada4 is no > failed. Yes, I understand, that if here is configuration like this: > > gmirror0 > gstripe0 > ada0 > ada1 > gstripe1 > ada2 > ada3 > > and administrator kills gstripe0, for example, geom_mirror will send > event, because from its point of view it is not administrative > action... > But such situations, IMHO, are not very often ones. Won't gmirror still report COMPLETE after a gmirror remove? So the script can look at the gmirror device, and see that it is still complete even though one of the providers were dropped and assume it was an administrative command that did it.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."