From owner-freebsd-fs@FreeBSD.ORG Tue Nov 18 19:50:01 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 D0BD7106564A; Tue, 18 Nov 2008 19:50:01 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout015.mac.com (asmtpout015.mac.com [17.148.16.90]) by mx1.freebsd.org (Postfix) with ESMTP id B938C8FC16; Tue, 18 Nov 2008 19:50:01 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_Q/RDFC20R9f2Fuvk1My3VQ)" Received: from mverma-lt.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp015.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KAJ00G9MOFC1K40@asmtp015.mac.com>; Tue, 18 Nov 2008 11:50:01 -0800 (PST) Message-id: <022C4222-63B2-4535-8B7E-0426E9CE2BEA@mac.com> From: Marcel Moolenaar To: Andriy Gapon In-reply-to: <4922FB81.50608@icyb.net.ua> Date: Tue, 18 Nov 2008 11:49:59 -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> 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: Tue, 18 Nov 2008 19:50:01 -0000 --Boundary_(ID_Q/RDFC20R9f2Fuvk1My3VQ) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT 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 Moolenaar xcllnt@mac.com --Boundary_(ID_Q/RDFC20R9f2Fuvk1My3VQ) Content-type: application/octet-stream; x-unix-mode=0644; name=gpart.diff Content-transfer-encoding: 7bit Content-disposition: attachment; filename=gpart.diff Index: part/g_part.c =================================================================== --- part/g_part.c (revision 185030) +++ part/g_part.c (working copy) @@ -1632,6 +1632,32 @@ } static void +g_part_done(struct bio *bp) +{ + char idx[8]; + struct g_part_entry *entry; + struct g_provider *pp; + size_t sz; + + /* + * Add partition index to the ident received from the + * underlying provider. This makes GPart compatible + * with partitioning schemes using geom_slice. ZFS, + * for example, compares the ident with on-disk meta- + * data and a mismatch causes the slice to be rejected. + */ + if (bp->bio_error == 0 && bp->bio_data[0] != '\0') { + pp = bp->bio_to; + entry = pp->private; + snprintf(idx, sizeof(idx), "s%d", entry->gpe_index); + sz = strlcat(bp->bio_data, idx, bp->bio_length); + if (sz >= bp->bio_length) + bp->bio_error = ENOSPC; + } + g_std_done(bp); +} + +static void g_part_start(struct bio *bp) { struct bio *bp2; @@ -1641,6 +1667,7 @@ struct g_part_table *table; struct g_kerneldump *gkd; struct g_provider *pp; + void (*bio_done)(struct bio *); pp = bp->bio_to; gp = pp->geom; @@ -1656,6 +1683,8 @@ return; } + bio_done = g_std_done; + switch(bp->bio_cmd) { case BIO_DELETE: case BIO_READ: @@ -1689,6 +1718,10 @@ if (g_handleattr_int(bp, "PART::offset", table->gpt_offset + entry->gpe_start)) return; + if (!strcmp("GEOM::ident", bp->bio_attribute)) { + bio_done = g_part_done; + break; + } if (!strcmp("GEOM::kerneldump", bp->bio_attribute)) { /* * Check that the partition is suitable for kernel @@ -1719,7 +1752,7 @@ g_io_deliver(bp, ENOMEM); return; } - bp2->bio_done = g_std_done; + bp2->bio_done = bio_done; g_io_request(bp2, cp); } --Boundary_(ID_Q/RDFC20R9f2Fuvk1My3VQ)--