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

[Pawel Jakub Dawidek]

On Wed, Jun 15, 2011 at 08:09:05AM -0600, Justin T. Gibbs wrote:
> 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.

I thought about that - I was wondering if we should allow given consumer
to veto the change, but it will be too complex for various reasons.
For example if you change disk size for your virtual machine it would be
hard to report the error back. Another problem is that when you have
more than one consumer and you start inform them about size change what
would you do if the last one returns an error? Would you inform the
previous consumers that provider shrinked? It might be too late.

Maybe the default behaviour (unless you override it) should be to
disconnect from such provider (eg. by sending the orphan event to
consumers that don't handle mediasize change)?

Currently if a GEOM class is offline and you resize partition that the
class "owns" and you bring the class online it won't be able to find its
metadata or will do something strange. We consider it an administrator
mistake. Doing online resize is a bit different but maybe not that much
different and we should also consider it the same?

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
FreeBSD committer                         http://www.FreeBSD.org
Am I Evil? Yes, I Am!                     http://yomoli.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20110615/eedd35b2/attachment.pgp