From owner-freebsd-fs@FreeBSD.ORG Wed Nov 26 22:55:19 2008 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 0EC6A1065678; Wed, 26 Nov 2008 22:55:19 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout022.mac.com (asmtpout022.mac.com [17.148.16.97]) by mx1.freebsd.org (Postfix) with ESMTP id DFB5C8FC1A; Wed, 26 Nov 2008 22:55:18 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [172.24.104.100] (natint3.juniper.net [66.129.224.36]) by asmtp022.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KAY00MOLQC54430@asmtp022.mac.com>; Wed, 26 Nov 2008 14:55:18 -0800 (PST) Message-id: From: Marcel Moolenaar To: Andriy Gapon In-reply-to: <492DBE1F.2040501@icyb.net.ua> Date: Wed, 26 Nov 2008 14:55:17 -0800 References: <4911C3E9.405@icyb.net.ua> <49198A1A.3080600@icyb.net.ua> <49227875.6090902@icyb.net.ua> <93FC5F5D-91CD-450B-B08D-5C5EC5A1C880@mac.com> <4922FB81.50608@icyb.net.ua> <022C4222-63B2-4535-8B7E-0426E9CE2BEA@mac.com> <492DBE1F.2040501@icyb.net.ua> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-fs@freebsd.org, freebsd-geom@freebsd.org Subject: Re: zfs: affected by geom_(mbr|bsd) => geom_part_(mbr|bsd) ? 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, 26 Nov 2008 22:55:19 -0000 On Nov 26, 2008, at 1:22 PM, Andriy Gapon wrote: > on 18/11/2008 21:49 Marcel Moolenaar said the following: >> On Nov 18, 2008, at 9:29 AM, Andriy Gapon wrote: >>> I just remembered that I saved old zpool.cache file before >>> "migrating" >>> the pool. >>> I looked at the diff of hexdumps and there are a number of >>> differences, >>> it's hard to understand them because the file is binary (actually it >>> seems to contain serialized name-value pairs), but one difference is >>> prominent: >>> ... >>> 00000260 64 65 76 69 64 00 00 00 00 00 00 09 00 00 00 01 >>> |devid...........| >>> ... >>> -00000270 00 00 00 15 61 64 3a 47 45 41 35 33 34 52 46 30 >>> |....ad:GEA534RF0| >>> -00000280 54 4b 33 35 41 73 31 73 33 00 00 00 00 00 00 28 >>> |TK35As1s3......(| >>> ... >>> +00000270 00 00 00 11 61 64 3a 47 45 41 35 33 34 52 46 30 >>> |....ad:GEA534RF0| >>> +00000280 54 4b 33 35 41 00 00 00 00 00 00 28 00 00 00 28 >>> |TK35A......(...(| >>> ... >>> >>> It looks like old "devid" value is "ad:GEA534RF0TK35As1s3" and new >>> one >>> is "ad:GEA534RF0TK35A". Just a reminder: actual zpool device is >>> ad6s2d. >>> >>> The new value is what is reported by diskinfo: >>> $ diskinfo -v ad6 >>> ad6 >>> ... >>> ad:GEA534RF0TK35A # Disk ident. >>> >>> $ diskinfo -v ad6s2 >>> ad6s2 >>> ... >>> ad:GEA534RF0TK35A # Disk ident. >>> >>> $ diskinfo -v ad6s2d >>> ad6s2d >>> ... >>> ad:GEA534RF0TK35A # Disk ident. >>> >>> Hmm, "indent" is reported to be the same for all three entities. >>> >>> I don't remember what diskinfo reported with pre-gpart kernel, but I >>> suspect that it was something different. >>> Could anybody please check this? (on 7.X machine without GEOM_PART). >>> >>> I quickly glimpsed through sources and it seems that this comes from >>> DIOCGIDENT GEOM ioctl i.e. "GEOM::ident" attribute. It seems that >>> geom_slice.c code has some special handling for that. >> Interesting. Can you try the attached patch to GPart: > > Marcel, > > unfortunately the patch caused a panic. > Unfortunately, again, I wasn't able to catch a proper dump, but I > remembered that the panic was in g_part_done+0x16. I see :-/ > In general, I am not sure if anything is really needed in this > direction. > First, I think that pjd has recently committed changes to trunk ZFS, > so that it doesn't need device ids anymore and uses some metadata in > the devices. > Second, there is a migration path that I used - export/import of a > pool. > > So unless this detail of backward compatibility is really needed > somewhere else... pjd told me that and since it was added for ZFS, I think I'll just drop it. Patching GEOM:ident this way is kinda ugly... Thanks for testing! -- Marcel Moolenaar xcllnt@mac.com