Date: Thu, 15 Nov 2007 13:43:11 +0000 From: Hugo Silva <hugo@barafranca.com> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: freebsd-current@FreeBSD.ORG Subject: Re: ZFS from FreeBSD -> Indiana -> FreeBSD - some problem Message-ID: <473C4CEF.7000105@barafranca.com> In-Reply-To: <20071115082556.GC80222@garage.freebsd.pl> References: <473AE404.9090605@restart.be> <473AF1BE.1060008@restart.be> <473BA651.1030109@egr.msu.edu> <20071115082556.GC80222@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
Pawel Jakub Dawidek wrote: > On Wed, Nov 14, 2007 at 08:52:17PM -0500, Adam McDougall wrote: > >> For what its worth, I ran across a similar issue. I moved a scsi card >> in my server which caused da2 and da3 (each with a separate zfs pool >> with no redundancy) become swapped, which I did not predict. ZFS was >> completely confused by this, and rather than swap cables and reboot, I >> decided to try the export and import. Worked fine. I was a little >> dissapointed and surprised that I had to take action, but more surprised >> that such a simple fix was possible (yet predicted) when the error >> message on sun's website basically indicated 'you are totally screwed, >> game over, data lost'. I wasn't in a situation were I would have lost >> any valuable data. Maybe it was terminally confused because both >> devices it wanted were in use by the other 'failed' pool. >> > > In my perforce branch, this is already improved. FreeBSD will detect > disk name changes, etc. It already does, but only with ATA disks. > > Wouldn't create the pool using GEOM_LABEL names solve this issue ? Any side effects of doing so ? Regards, Hugo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?473C4CEF.7000105>