From owner-freebsd-fs@FreeBSD.ORG Wed Oct 24 17:03:01 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F94E16A417; Wed, 24 Oct 2007 17:03:01 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id E985A13C4A6; Wed, 24 Oct 2007 17:03:00 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l9OGeaa1055119; Wed, 24 Oct 2007 10:40:37 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <471F756E.2020008@samsco.org> Date: Wed, 24 Oct 2007 10:40:14 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <471F5B46.9050106@fsn.hu> <20071024155723.GA1431@garage.freebsd.pl> In-Reply-To: <20071024155723.GA1431@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Wed, 24 Oct 2007 10:40:37 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and disk naming change (ex. da0->da4) 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, 24 Oct 2007 17:03:01 -0000 Pawel Jakub Dawidek wrote: > On Wed, Oct 24, 2007 at 04:48:38PM +0200, Attila Nagy wrote: >> Hello, >> >> I have an experimental (but that does not mean, I wouldn't like to get >> my data back :) zpool, which was created with something like this: >> zpool create people raidz2 /dev/da0 /dev/da3 /dev/da4, etc >> >> The problem is those device names have been changed during the next >> reboot (the cause of this is irrelevant, but mainly because some of them >> were not attached at the original boot, just later, so at the next >> reboot the disks came up in a different order), so now I have: >> zpool status >> pool: people >> state: UNAVAIL >> status: One or more devices could not be opened. There are insufficient >> replicas for the pool to continue functioning. >> action: Attach the missing device and online it using 'zpool online'. >> see: http://www.sun.com/msg/ZFS-8000-D3 >> scrub: none requested >> config: >> >> NAME STATE READ WRITE CKSUM >> people UNAVAIL 0 0 0 insufficient replicas >> raidz2 UNAVAIL 0 0 0 insufficient replicas >> da0 UNAVAIL 0 0 0 cannot open >> da3 ONLINE 0 0 0 >> da4 FAULTED 0 0 0 corrupted data >> da5 FAULTED 0 0 0 corrupted data >> da6 FAULTED 0 0 0 corrupted data >> da7 FAULTED 0 0 0 corrupted data >> da8 FAULTED 0 0 0 corrupted data >> da9 FAULTED 0 0 0 corrupted data >> >> (it seems da3 is still da3 :) >> >> My question is: what now? Is it possible to regain the pool, or is it >> totally busted now? I am not sure that I can figure out which device is >> which now... >> >> I've only played with ZFS on Solaris with FC targets, and there I've >> never faced this problem, because of the static naming. > > ZFS caches components names in /boot/zfs/zpool.cache. You may remove > this file and import the pool again. > > ZFS can handle name changes, but currently only with ATA disks. It can > find disk using it's ID. I've a patch for SCSI disks, but it's probably > not entirely correct: > > http://people.freebsd.org/~pjd/patches/scsi_da_ident.patch > > We need some SCSI guru to implement it properly. > >> ps: I guess next time I will use glabel -I love that- to provide base >> devices... > > Yes, glabel seems like a good work-around for now. In some cases we will > never be able to provide disk's ID, eg. for USB pen-drives, etc. > Serial numbers are not reliably unique in SCSI. Identifying SCSI disks in a unique way has been a problem for decades since such uniqueness was never mandated in any specs and the vendors never agreed on if or how to do it in a uniform way. The best you can do is to look at the data from VPD pages 0x81 and 0x83 and hueristically guess if what you're told is usable. SAS is the first SCSI-like technology that has mandated unique device ID's; I believe that FC only guarantees unique port ID's, but for a multi-port FC device, it's still a guess as to whether you'll be able to determine device uniqueness. However, since multi-pathing is such a desired feature with FC, it's a good bet these days that you'll be able to extract a unique device ID from each device. If you'd like some example code on how to do VPD queries from userland or even from the kernel, I'd be happy to show you. Scott