Bug#653929: Bug #696119 probably has the fix to this bug
Tags: patch
Today I filed a bug about this same problem, having found this earlier
report too late. I believe the patch on bug #696119 will address this
problem (which is not seen on freebsd due to libc differences).
As I'm a newbie at the debian bugtracker I'm not sure how to merge the
two bugs, or even if that's how it's done here. I hope I'm not doing
ill by repeating my patch here.
Index: zfsutils-9.0/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c
===================================================================
--- zfsutils-9.0.orig/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c 2012-12-16 12:15:18.000000000 -0600
+++ zfsutils-9.0/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c 2012-12-16 13:11:34.171723989 -0600
@@ -3087,6 +3087,8 @@
(void) ioctl(zhp->zpool_hdl->libzfs_fd, ZFS_IOC_VDEV_SETPATH, &zc);
}
+#define PATH_BUF_LEN 64
+
/*
* Given a vdev, return the name to display in iostat. If the vdev has a path,
* we use that, stripping off any leading "/dev/dsk/"; if not, we use the type.
@@ -3108,7 +3110,8 @@
{
char *path, *devid;
uint64_t value;
- char buf[64];
+ char buf[PATH_BUF_LEN];
+ char tmpbuf[PATH_BUF_LEN];
vdev_stat_t *vs;
uint_t vsc;
int have_stats;
@@ -3204,6 +3207,7 @@
* If it's a raidz device, we need to stick in the parity level.
*/
if (strcmp(path, VDEV_TYPE_RAIDZ) == 0) {
+
verify(nvlist_lookup_uint64(nv, ZPOOL_CONFIG_NPARITY,
&value) == 0);
(void) snprintf(buf, sizeof (buf), "%s%llu", path,
@@ -3220,9 +3224,9 @@
verify(nvlist_lookup_uint64(nv, ZPOOL_CONFIG_ID,
&id) == 0);
- (void) snprintf(buf, sizeof (buf), "%s-%llu", path,
- (u_longlong_t)id);
- path = buf;
+ (void) snprintf(tmpbuf, sizeof (tmpbuf), "%s-%llu",
+ path, (u_longlong_t)id);
+ path = tmpbuf;
}
}
Reply to: