Date: Tue, 5 Feb 2008 13:46:26 +0100 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Dag-Erling Sm??rgrav <des@des.no> Cc: freebsd-fs@freebsd.org, Alexander Leidinger <Alexander@Leidinger.net> Subject: Re: ZFS: invalid label -- what is expected? (solved) Message-ID: <20080205124626.GB95316@garage.freebsd.pl> In-Reply-To: <86lk5zy5a4.fsf@ds4.des.no> References: <20080204092150.vprsphymqoog8cw4@webmail.leidinger.net> <20080204194936.thzddva9a8s4cwsg@webmail.leidinger.net> <86lk5zy5a4.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
--MfFXiAuoTsnnDAfZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 05, 2008 at 01:08:35PM +0100, Dag-Erling Sm??rgrav wrote: > Alexander Leidinger <Alexander@Leidinger.net> writes: > > After digging around in the ZFS sources and investigating some on-disk > > structures (with some confusing results, as the data didn't seem > > corrupt to me), I exported the pool. After that all disk where again > > in the online state. All are connected via firewire and came back in a > > different order (daX) after a reboot (panic). It seems our > > implementation wasn't able to handle this without the reimport help. >=20 > IIRC, it works fine for ATA devices but not for CAM devices (which > include SCSI, SAS, USB, Firewire). I'm not sure whether pjd@ is working > on that, but when creating a new pool, you can save yourself some > trouble down the road by labeling the disks. It is properly done in perforce already. If component can't be found, ZFS tries to look it up by checking all GEOM providers one by one. This should solve all those issues and doesn't rely on serial numbers which are not always there. > You can also fix an existing pool by replacing each disk one by one with > larger labeled disks - they must be larger, since the label will consume > some space and ZFS will refuse to replace a disk in a raidz pool with > one that is smaller than the smallest pre-existing disk. As a bonus, > you will end up with a larger pool than you started out with :) >=20 > I've been toying with the idea of writing a gnop-like geom that allows a > disk to be referenced by its serial number if the underlying driver is > able to supply it. That would bypass glabel's disk-shrinking issue when > working on whole disks. Been there, done that. You can probably find discussion about this in the archives. The consensus (well, not mine) was that it is not good idea. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --MfFXiAuoTsnnDAfZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHqFqgForvXbEpPzQRAgjWAKDWyvIR5dvFwgwpa89l3HJmHaBTZACgsffH K5GYr7PsVO5+SPUWM8kwZWc= =qlgN -----END PGP SIGNATURE----- --MfFXiAuoTsnnDAfZ--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080205124626.GB95316>