Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 18 Nov 2008 11:49:59 -0800
From:      Marcel Moolenaar <xcllnt@mac.com>
To:        Andriy Gapon <avg@icyb.net.ua>
Cc:        freebsd-fs@freebsd.org, freebsd-geom@freebsd.org
Subject:   Re: zfs: affected by geom_(mbr|bsd) => geom_part_(mbr|bsd) ?
Message-ID:  <022C4222-63B2-4535-8B7E-0426E9CE2BEA@mac.com>
In-Reply-To: <4922FB81.50608@icyb.net.ua>
References:  <4911C3E9.405@icyb.net.ua> <49198A1A.3080600@icyb.net.ua> <B6997A5A-1B56-4325-A24A-EF90AF8C6A6A@mac.com> <49227875.6090902@icyb.net.ua> <93FC5F5D-91CD-450B-B08D-5C5EC5A1C880@mac.com> <4922FB81.50608@icyb.net.ua>

next in thread | previous in thread | raw e-mail | index | archive | help

--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)--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?022C4222-63B2-4535-8B7E-0426E9CE2BEA>