From owner-freebsd-fs@FreeBSD.ORG Wed Jun 15 15:24:27 2011 Return-Path: Delivered-To: fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B8F61065673; Wed, 15 Jun 2011 15:24:27 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 163348FC15; Wed, 15 Jun 2011 15:24:26 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 2143545C89; Wed, 15 Jun 2011 17:24:25 +0200 (CEST) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 1A69145683; Wed, 15 Jun 2011 17:24:19 +0200 (CEST) Date: Wed, 15 Jun 2011 17:24:14 +0200 From: Pawel Jakub Dawidek To: "Justin T. Gibbs" Message-ID: <20110615152414.GA2068@garage.freebsd.pl> References: <201106141710.p5EHAXYS044119@svn.freebsd.org> <20110615094202.GB1975@garage.freebsd.pl> <4DF8A934.8070500@FreeBSD.org> <20110615132458.GK1975@garage.freebsd.pl> <4DF8BD01.5040206@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline In-Reply-To: <4DF8BD01.5040206@FreeBSD.org> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: fs@FreeBSD.org Subject: Re: svn commit: r223089 - in head: sys/cam/ata sys/cam/scsi sys/geom sys/sys usr.sbin/diskinfo X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 15:24:27 -0000 --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 ot= her > 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? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --J/dobhs11T7y2rNN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk34zp0ACgkQForvXbEpPzTOCwCgovlkOfeW8xcjeaF2U5AlmS5z fD4An2HRmfD/5PIPhFt8Jshq7Z/qR1ty =vaLO -----END PGP SIGNATURE----- --J/dobhs11T7y2rNN--