svn commit: r223089 - in head: sys/cam/ata sys/cam/scsi sys/geom
Pawel Jakub Dawidek
pjd at FreeBSD.org
Wed Jun 15 15:24:27 UTC 2011
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
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20110615/eedd35b2/attachment.pgp
More information about the freebsd-fs