Date: Wed, 15 Jun 2011 08:09:05 -0600 From: "Justin T. Gibbs" <gibbs@FreeBSD.org> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: fs@FreeBSD.org Subject: Re: svn commit: r223089 - in head: sys/cam/ata sys/cam/scsi sys/geom sys/sys usr.sbin/diskinfo Message-ID: <4DF8BD01.5040206@FreeBSD.org> In-Reply-To: <20110615132458.GK1975@garage.freebsd.pl> References: <201106141710.p5EHAXYS044119@svn.freebsd.org> <20110615094202.GB1975@garage.freebsd.pl> <4DF8A934.8070500@FreeBSD.org> <20110615132458.GK1975@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DF8BD01.5040206>