svn commit: r223089 - in head: sys/cam/ata sys/cam/scsi sys/geom sys/sys usr.sbin/diskinfo

[Justin T. Gibbs]

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