[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#696119: marked as done (`zpool status` incorrectly names raidz vdevs)



Your message dated Fri, 19 Sep 2014 23:04:26 +0000
with message-id <E1XV7E2-0007cS-4S@franck.debian.org>
and subject line Bug#653929: fixed in zfsutils 10.1~svn271683-2
has caused the Debian Bug report #653929,
regarding `zpool status` incorrectly names raidz vdevs
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
653929: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653929
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: libzfs1
Version: 9.0-3
Severity: normal
Tags: patch

"zpool status" incorrectly prints "raidz" vdevs as "-0" instead of
"raidz1-0", e.g.
    $ zpool status mpool 
      pool: mpool
     state: ONLINE
     scan: scrub repaired 0 in 0h52m with 0 errors on Sun Dec 16 12:43:40 2012
    config:

            NAME        STATE     READ WRITE CKSUM
            mpool       ONLINE       0     0     0
              -0        ONLINE       0     0     0
                ada0p3  ONLINE       0     0     0
                ada1p3  ONLINE       0     0     0
                ada2p3  ONLINE       0     0     0
should be
    $ LD_LIBRARY_PATH=debian/libzfs1/lib zpool status mpool 
      pool: mpool
     state: ONLINE
     scan: scrub repaired 0 in 0h52m with 0 errors on Sun Dec 16 12:43:40 2012
    config:

            NAME        STATE     READ WRITE CKSUM
            mpool       ONLINE       0     0     0
              raidz1-0  ONLINE       0     0     0
                ada0p3  ONLINE       0     0     0
                ada1p3  ONLINE       0     0     0
                ada2p3  ONLINE       0     0     0


I investigated the problem and it turns out to be bad use of snprintf (the
output buffer is the same as one of the positional arguments); Solaris and
possibly FreeBSD libc behave differently than glibc in this case. (FreeBSD 9.0
doesn't exhibit the problem)

I have a patch derived from the zfsonlinux project, where they have also
fixed the bug.  My patch is simply a combination of these two patches:

https://github.com/zfsonlinux/zfs/commit/858219cc4e44
https://github.com/zfsonlinux/zfs/commit/fc24f7c887a0

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: kfreebsd-amd64 (x86_64)

Kernel: kFreeBSD 9.0-2-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libzfs1 depends on:
ii  libbsd0     0.4.2-1
ii  libc0.1     2.13-37
ii  libgeom1    9.0+ds1-3
ii  libnvpair1  9.0-3
ii  libumem1    9.0-3
ii  libuutil1   9.0-3

libzfs1 recommends no packages.

Libzfs1 suggests no packages.

-- no debconf information


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;
 		}
 	}
 

--- End Message ---
--- Begin Message ---
Source: zfsutils
Source-Version: 10.1~svn271683-2

We believe that the bug you reported is fixed in the latest version of
zfsutils, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 653929@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Christoph Egger <christoph@debian.org> (supplier of updated zfsutils package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Fri, 19 Sep 2014 15:43:47 -0700
Source: zfsutils
Binary: libuutil2 libuutil2-udeb libnvpair2 libnvpair2-udeb libzfs2 libzfs2-udeb zfsutils zfsutils-udeb libumem2 libumem2-udeb libzpool2 libzpool2-udeb
Architecture: source
Version: 10.1~svn271683-2
Distribution: experimental
Urgency: medium
Maintainer: GNU/kFreeBSD Maintainers <debian-bsd@lists.debian.org>
Changed-By: Christoph Egger <christoph@debian.org>
Description:
 libnvpair2 - illumos name-value pair library
 libnvpair2-udeb - illumos name-value pair library (debian-installer version) (udeb)
 libumem2   - illumos memory-management library
 libumem2-udeb - illumos memory-management library (debian-installer version) (udeb)
 libuutil2  - illumos userland utility library
 libuutil2-udeb - illumos userland utility library (debian-installer version) (udeb)
 libzfs2    - illumos ZFS library
 libzfs2-udeb - illumos ZFS library (debian-installer version) (udeb)
 libzpool2  - illumos interface library to manage ZFS storage pools
 libzpool2-udeb - illumos interface library to manage ZFS storage pools (debian-ins (udeb)
 zfsutils   - command-line tools to manage ZFS filesystems
 zfsutils-udeb - command-line tools to manage ZFS filesystems (debian-installer ve (udeb)
Closes: 653929 762199
Changes:
 zfsutils (10.1~svn271683-2) experimental; urgency=medium
 .
   [ Steven Chamberlain ]
   * bug762199.patch: st_size is only meaningful for regular files;
     existing code did not detect any zpools for import (Closes: #762199)
   * cddl/compat/opensolaris/misc/fsshare.c: don't include missing/unused
     libutil.h;  not needed and caused FTBFS on kfreebsd-i386 only
   * Bump minimum GRUB version to 2.02~beta2-11 for lz4_compress support;
     enabled by default for metadata (but not file contents, yet)
   * Fix display of RAID-Z devices in "zpool status" (Thanks, Jeff Epler!
     Closes: #653929)
Checksums-Sha1:
 ce29b34daecdf4a8c1554bceb318e009fcd66d96 2954 zfsutils_10.1~svn271683-2.dsc
 428b9a18585d8e1dc63ece10a125caa4689aa3ea 48540 zfsutils_10.1~svn271683-2.debian.tar.xz
Checksums-Sha256:
 cc22e3a7202050cc3d3836db3a4532028527fb5ae44d981105c2be7e6b5caf2c 2954 zfsutils_10.1~svn271683-2.dsc
 e2ad7674bddb0eaca7c8476a95ef3aea11dd383b5c91d01199bbfbf99b340821 48540 zfsutils_10.1~svn271683-2.debian.tar.xz
Files:
 4187e9d5b11f627f6e7b52b17a6e76f6 2954 admin optional zfsutils_10.1~svn271683-2.dsc
 838e82d3136dc8d43735f2174c6906b2 48540 admin optional zfsutils_10.1~svn271683-2.debian.tar.xz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJUHLHTAAoJEKv/7bJACMb5yHkQAKW6Yx36odyIfdeZxmQVNjn9
hBpUP13XbNVz5hQ8heELDQ9c8v/TluikyCajkBLekKt2+vr2z24E6E9EkrnJv3Ij
fs9XRIsvbXHepv4qw8l+M24rg0te+1CbDIABpD382XWz6bSOq1N6+EjpBpKaUwwR
wK21bEC0w7RYd8yUr3jXSZz0QOG3/QY3ZqltlH4DulJKVOeIMHZ9HhcLGAZASKMT
Sv8kpgDvBSD1LMFyWj8pqlqACdgns/BBFWTjLj3jCunJ7DCkaoU5BBXGkUqJFh++
rqi/K9cTLtCNmZL3Zp7UNJDOlxMS6LKuBgAu3LAZJhWdSx3V7zSnawJL/W1TL/ac
oSGqYpC3HGjvZS3ErCtMbNcK3j3nMotqhs4v1Kue5OkI/TZFRB4aAarXcIJBDRSA
S1qILlL4yTI8Ah9sw6Mul7PtXcpdxFebIMUOZCwkzcMH4/ehP07g/iu/H7dFSGSS
d9GXVWAzmp4EEGcnbtoLTCAnoEqvrbDvf2WXUrKkGpioyFDh+uIJ9u/B58Bf3RqW
VRh3iZn2AIFK4CaOWLKatJBih15uh3iEdtx8LK0ziHqYGPgAYyk3RJ6DsfCyBJ8j
KFF5hBGlnRM8EHIyzgO5EUTLdxC0N3pzK1a9p/Jr6q47GSWxPa6O8kGpdE2PDgkI
tySEEpkag+oQs6ATe9ly
=G+b0
-----END PGP SIGNATURE-----

--- End Message ---

Reply to: