From owner-freebsd-fs@FreeBSD.ORG Wed Nov 26 21:22:47 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 EFF7B1065675; Wed, 26 Nov 2008 21:22:47 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from hosted.kievnet.com (hosted.kievnet.com [193.138.144.10]) by mx1.freebsd.org (Postfix) with ESMTP id 9D5248FC23; Wed, 26 Nov 2008 21:22:47 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost ([127.0.0.1] helo=edge.pp.kiev.ua) by hosted.kievnet.com with esmtpa (Exim 4.62) (envelope-from ) id 1L5RqP-000JlE-78; Wed, 26 Nov 2008 23:22:45 +0200 Message-ID: <492DBE1F.2040501@icyb.net.ua> Date: Wed, 26 Nov 2008 23:22:39 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.17 (X11/20081005) MIME-Version: 1.0 To: Marcel Moolenaar 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> In-Reply-To: <022C4222-63B2-4535-8B7E-0426E9CE2BEA@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 21:22:48 -0000 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. 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... -- Andriy Gapon