svn commit: r223089 - in head: sys/cam/ata sys/cam/scsi sys/geom
Justin T. Gibbs
gibbs at FreeBSD.org
Wed Jun 15 14:09:11 UTC 2011
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
> > 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.
More information about the freebsd-fs