From owner-freebsd-fs@FreeBSD.ORG Wed Jun 15 12:47:30 2011 Return-Path: Delivered-To: fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54D371065673; Wed, 15 Jun 2011 12:47:30 +0000 (UTC) (envelope-from gibbs@FreeBSD.org) Received: from aslan.scsiguy.com (mail.scsiguy.com [70.89.174.89]) by mx1.freebsd.org (Postfix) with ESMTP id 2CA2F8FC0C; Wed, 15 Jun 2011 12:47:29 +0000 (UTC) Received: from Justins-MacBook-Pro.local (macbook.scsiguy.com [192.168.0.99]) (authenticated bits=0) by aslan.scsiguy.com (8.14.4/8.14.4) with ESMTP id p5FCmpuT020189 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 15 Jun 2011 06:48:51 -0600 (MDT) (envelope-from gibbs@FreeBSD.org) Message-ID: <4DF8A9E1.6050501@FreeBSD.org> Date: Wed, 15 Jun 2011 06:47:29 -0600 From: "Justin T. Gibbs" Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <201106141710.p5EHAXYS044119@svn.freebsd.org> <20110615094202.GB1975@garage.freebsd.pl> In-Reply-To: <20110615094202.GB1975@garage.freebsd.pl> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (aslan.scsiguy.com [70.89.174.89]); Wed, 15 Jun 2011 06:48:51 -0600 (MDT) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: fs@FreeBSD.org Subject: Re: svn commit: r223089 - in head: sys/cam/ata sys/cam/scsi sys/geom sys/sys usr.sbin/diskinfo X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gibbs@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 12:47:30 -0000 On 6/15/11 3:42 AM, Pawel Jakub Dawidek wrote: > On Tue, Jun 14, 2011 at 05:10:33PM +0000, Justin T. Gibbs wrote: > > Author: gibbs > > Date: Tue Jun 14 17:10:32 2011 > > New Revision: 223089 > > URL: http://svn.freebsd.org/changeset/base/223089 > > > > Log: > [...] > > sys/sys/geom/geom.h: > > sys/geom/geom_event.c: > > - Provide the g_attr_changed() function that providers > > can use to advertise attribute changes. > > - Perform delivery of attribute change notifications > > from a thread context via the standard GEOM event > > mechanism. > > Would be nice to discuss it before the commit (or did I miss the > dicussion?). I thought we discussed this at BSDCAN, but perhaps it was when I was talking with mav? Sorry about that. > I was working on something that could be easly merged with > your changes. I had a patch to implement provider's properties change > notification to consumers and devd: > > http://people.freebsd.org/~pjd/patches/geom_property_change.patch > > Currently it implements only mediasize changes, so the upper layers can > act accordingly. The patch also implements ZFS bits to detect vdev size > changes and eventually autoexpand the pool. > > Could you look at the patch and see how we could add property changes to > your API? You say "property," I say "attribute". I used GEOM's string names for properties, you used flags. Other than that, I don't see much difference in the implementations. As far as supporting size changes in the API I committed, the intention is for the API to support notification of arbitrary provider changes, but changes that don't necessarily require consumers to go through a costly "re-taste process". If we define a string constant for the size property, emit that via "g_attr_changed()" in all the places you currently emit g_property_change(), and use strcmp instead of bit tests in your handlers, it should work. If you'd like, I can merge your changes into the API. However, I leave for a two week vacation on Friday, so it will have to be after that. One other issue I need to resolve is that notifying ZFS of things like a physical path change opens us up to lock order reversals. What I'd really like ZFS to do is, during any vdev config generation call, just call a vdev method to refresh attributes. We could then just post a SPA async event from the attr_changed handler and do all of the attribute fetching from the "refresh" method knowing that locks are acquired in the correct order (g_topology last). -- Justin