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 7:24 AM, Pawel Jakub Dawidek wrote:
>  On Wed, Jun 15, 2011 at 06:44:36AM -0600, Justin T. Gibbs wrote:
> >> 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.
>
>  Well, you notify about attributes passed around with BIO_GETATTR, my
>  change is about changes in provider properties like mediasize and maybe
>  name in the future. This is different namespace. But I agree that
>  reserving and using "mediasize" or "GEOM::mediasize" should be fine.

Ah.  I understand your distinction now.  I think it would be best
to just have one notification scheme regardless of how the
properties/attributes are accessed (directly in a struct or via a
getattr call).  I even considered folding the spoiling stuff into
this but then thought that might be considered too radical a change.

As for a size change, at what point is it safe to change the size field
in the provider?  I know that the ZFS vdevs cache the size data, so the
provider bumping its size field shouldn't be a problem, but what about other
GEOM consumers?  Will the GEOM RAID transforms suddenly and unintentionaly
start putting their label information in a different location?  Similar
situations may apply to other properties/attributes.

--
Justin