From uqs@spoerlein.net  Sat Jun  6 14:55:03 2009
Return-Path: <uqs@spoerlein.net>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 991D9106568E;
	Sat,  6 Jun 2009 14:55:03 +0000 (UTC)
	(envelope-from uqs@spoerlein.net)
Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2])
	by mx1.freebsd.org (Postfix) with ESMTP id 0D7CD8FC22;
	Sat,  6 Jun 2009 14:55:02 +0000 (UTC)
	(envelope-from uqs@spoerlein.net)
Received: from coyote.spoerlein.net (e180164234.adsl.alicedsl.de [85.180.164.234])
	by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n56EswLt097796
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 6 Jun 2009 16:54:58 +0200 (CEST)
	(envelope-from uqs@spoerlein.net)
Received: from coyote.spoerlein.net (localhost [127.0.0.1])
	by coyote.spoerlein.net (8.14.3/8.14.3) with ESMTP id n56Est6u000470
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 6 Jun 2009 16:54:55 +0200 (CEST)
	(envelope-from uqs@coyote.spoerlein.net)
Received: (from uqs@localhost)
	by coyote.spoerlein.net (8.14.3/8.14.3/Submit) id n56EssWN000469;
	Sat, 6 Jun 2009 16:54:54 +0200 (CEST)
	(envelope-from uqs)
Message-Id: <200906061454.n56EssWN000469@coyote.spoerlein.net>
Date: Sat, 6 Jun 2009 16:54:54 +0200 (CEST)
From: Ulrich Spoerlein <uqs@spoerlein.net>
To: FreeBSD-gnats-submit@freebsd.org
Cc: kmacy@freebsd.org
Subject: [zfs] assertion failed for zdb(8) usage
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         135314
>Category:       bin
>Synopsis:       [zfs] assertion failed for zdb(8) usage
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    pjd
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Jun 06 15:00:15 UTC 2009
>Closed-Date:    Mon Sep 28 17:53:48 UTC 2009
>Last-Modified:  Mon Oct 19 20:10:06 UTC 2009
>Originator:     Ulrich Spoerlein
>Release:        FreeBSD 7.2-STABLE i386
>Organization:
>Environment:
7.2-STABLE updated/built late May, following zpool:

root@coyote:~# zdb
tank
    version=13
    name='tank'
    state=0
    txg=7697828
    pool_guid=703138832090335500
    hostid=2892912347
    hostname='unset'
    vdev_tree
        type='root'
        id=0
        guid=703138832090335500
        children[0]
                type='mirror'
                id=0
                guid=3091292675388649821
                metaslab_array=14
                metaslab_shift=30
                ashift=12
                asize=1000199946240
                is_log=0
                children[0]
                        type='disk'
                        id=0
                        guid=4881503163781172225
                        path='/dev/ad4.eli'
                        whole_disk=0
                        DTL=97
                children[1]
                        type='disk'
                        id=1
                        guid=12333765091756463941
                        path='/dev/da0.eli'
                        whole_disk=0
                        DTL=96
                        offline=1


>Description:
I read the post about deduplication at
http://blogs.sun.com/erickustarz/entry/how_dedupalicious_is_your_pool which
comes with a sample zdb(8) invocation which fails on FreeBSD 7.2
>How-To-Repeat:
root@coyote:~# zdb -L -S user:all tank | tee /tmp/tank_out.txt
Assertion failed: (��), function rwlp->rw_count == 0, file /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/kernel.c, line 195.
Abort (core dumped)
Exit 134

Fiddling with simple options like -u makes it core dump, too.

Someone should try this on 8-CURRENT to figure out if this is a MFC artefact.
>Fix:


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-fs 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Sat Jun 6 16:09:30 UTC 2009 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=135314 
State-Changed-From-To: open->feedback 
State-Changed-By: pjd 
State-Changed-When: pon 28 wrz 2009 17:25:25 UTC 
State-Changed-Why:  
Can you reproduce it on 8.0-RC1? It works for me. 


Responsible-Changed-From-To: freebsd-fs->pjd 
Responsible-Changed-By: pjd 
Responsible-Changed-When: pon 28 wrz 2009 17:25:25 UTC 
Responsible-Changed-Why:  
I'll take this one. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=135314 
State-Changed-From-To: feedback->closed 
State-Changed-By: pjd 
State-Changed-When: pon 28 wrz 2009 17:53:12 UTC 
State-Changed-Why:  
Close this PR, as I was able to reproduce the problem on older system, 
but I cannot reproduce it on HEAD/8.0. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=135314 

From: Henno Schooljan <henno@schooljan.nl>
To: bug-followup@FreeBSD.org, uqs@spoerlein.net
Cc:  
Subject: Re: bin/135314: [zfs] assertion failed for zdb(8) usage
Date: Sun, 18 Oct 2009 22:25:31 +0200

 I can reproduce this on 8.0-RC1 i386. On amd64 it works fine.
 
 Henno

From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= <uqs@spoerlein.net>
To: Henno Schooljan <henno@schooljan.nl>
Cc: bug-followup@FreeBSD.org
Subject: Re: bin/135314: [zfs] assertion failed for zdb(8) usage
Date: Mon, 19 Oct 2009 20:35:08 +0200

 On Sun, 18.10.2009 at 22:25:31 +0200, Henno Schooljan wrote:
 > I can reproduce this on 8.0-RC1 i386. On amd64 it works fine.
 
 Hi Henno, looks like we need to break this down further, here's what
 works for me:
 
 - 9-CURRENT, i386, a real ZFS pool
 - 8.0-RC1, i386 (ok, VBox), a test ZFS pool with little data
 - 8.0-RC1, amd64, a real ZFS pool
 
 Perhaps this is related to the zpool/zfs version you are using? Also,
 I'm working with single disk pools, no RAID, etc.
 
 Regards,
 Uli

From: Henno Schooljan <henno@schooljan.nl>
To: =?iso-8859-1?Q?Ulrich_Sp=F6rlein?= <uqs@spoerlein.net>,
        bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/135314: [zfs] assertion failed for zdb(8) usage
Date: Mon, 19 Oct 2009 21:54:19 +0200

 On 19 okt 2009, at 20:35, Ulrich Sp=F6rlein wrote:
 
 > Hi Henno, looks like we need to break this down further, here's what
 > works for me:
 >
 > - 9-CURRENT, i386, a real ZFS pool
 > - 8.0-RC1, i386 (ok, VBox), a test ZFS pool with little data
 > - 8.0-RC1, amd64, a real ZFS pool
 >
 > Perhaps this is related to the zpool/zfs version you are using? Also,
 > I'm working with single disk pools, no RAID, etc.
 >
 
 Maybe I'm on to something. When I boot the 8.0-RC1-i386-livefs.iso CD =20=
 
 (to get an environment as clean and reproducible as possible), go to =20
 the repair/fixit/live filesystem prompt from CD, and issue the =20
 following commands it fails for me on two different computers:
 
 # kldload /mnt2/boot/kernel/opensolaris.ko
 # kldload /mnt2/boot/kernel/zfs.ko
 # mkdir /boot/zfs
 # zpool create -m /mnt tank /dev/ad4
 # zdb -i tank
 
 (/dev/ad4 is my dedicated drive for my non-redundant pool)
 
 However, when I do this:
 
 # kldload /mnt2/boot/kernel/opensolaris.ko
 # kldload /mnt2/boot/kernel/zfs.ko
 # mkdir /boot/zfs
 # zpool create /dev/ad4
 # zdb -i tank
 
 it succeeds. The only difference I see is that the pool is now mounted =20=
 
 at /mnt instead of the default /tank. When I change it to /whatever by =20=
 
 doing
 
 # zfs set mountpoint=3D/whatever tank
 
 a zdb -i tank fails again.
 
 When I then revert it by doing
 
 # zfs set mountpoint=3D/tank tank
 
 the zdb -i tank still fails. So I can only seem to get it to work by =20
 creating a zpool with the default /tank mountpoint by not using the -m =20=
 
 parameter.
 
 In summary:
 
 # zpool create /dev/ad4
 # zdb -i tank
 
 succeeds, mountpoint /tank (also verified via zfs get mountpoint tank)
 
 # zpool create -m /tank /dev/ad4
 # zdb -i tank
 
 fails, mountpoint also /tank (also verified via zfs get mountpoint =20
 tank).
 
 What would be the difference between these cases, and can anyone also =20=
 
 reproduce this using a i386 8.0-RC1 livefs CD and a dedicated drive?
 
 regards,
 
 Henno=

From: Henno Schooljan <henno@schooljan.nl>
To: =?iso-8859-1?Q?Ulrich_Sp=F6rlein?= <uqs@spoerlein.net>,
        bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/135314: [zfs] assertion failed for zdb(8) usage
Date: Mon, 19 Oct 2009 21:58:07 +0200

 --Apple-Mail-16-649696695
 Content-Transfer-Encoding: quoted-printable
 Content-Type: text/plain;
 	charset=iso-8859-1;
 	format=flowed;
 	delsp=yes
 
 
 On 19 okt 2009, at 20:35, Ulrich Sp=F6rlein wrote:
 >
 > Hi Henno, looks like we need to break this down further, here's what
 > works for me:
 >
 > - 9-CURRENT, i386, a real ZFS pool
 > - 8.0-RC1, i386 (ok, VBox), a test ZFS pool with little data
 > - 8.0-RC1, amd64, a real ZFS pool
 >
 > Perhaps this is related to the zpool/zfs version you are using? Also,
 > I'm working with single disk pools, no RAID, etc.
 >
 
 Sorry, I omitted the zpool name parameter 'tank' in the scenarios:
 
 In summary:
 
 # zpool create tank /dev/ad4
 # zdb -i tank
 
 succeeds, mountpoint /tank (also verified via zfs get mountpoint tank)
 
 # zpool create -m /tank tank /dev/ad4
 # zdb -i tank
 
 fails, mountpoint also /tank (also verified via zfs get mountpoint =20
 tank).
 
 The 8.0-RC1 CD is using ZFS version 13.
 
 Henno=
 
 --Apple-Mail-16-649696695
 Content-Transfer-Encoding: quoted-printable
 Content-Type: text/html;
 	charset=iso-8859-1
 
 <html><head></head><body style=3D"word-wrap: break-word; =
 -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
 "><br><div><div>On 19 okt 2009, at 20:35, Ulrich Sp=F6rlein =
 wrote:</div><blockquote type=3D"cite"><div><font =
 class=3D"Apple-style-span" color=3D"#000000"><br></font>Hi Henno, looks =
 like we need to break this down further, here's what<br>works for =
 me:<br><br>- 9-CURRENT, i386, a real ZFS pool<br>- 8.0-RC1, i386 (ok, =
 VBox), a test ZFS pool with little data<br>- 8.0-RC1, amd64, a real ZFS =
 pool<br><br>Perhaps this is related to the zpool/zfs version you are =
 using? Also,<br>I'm working with single disk pools, no RAID, =
 etc.<br><br></div></blockquote></div><br><div>Sorry, I omitted the zpool =
 name parameter 'tank' in the scenarios:</div><div><br></div>In =
 summary:<br><br># zpool create tank /dev/ad4<br># zdb -i =
 tank<br><br>succeeds, mountpoint /tank (also verified via zfs get =
 mountpoint tank)<br><br># zpool create -m /tank tank /dev/ad4<br># zdb =
 -i tank<br><br><div>fails, mountpoint also /tank (also verified via zfs =
 get mountpoint tank).&nbsp;</div><div><br></div><div>The 8.0-RC1 CD is =
 using ZFS version 13.</div><div><br></div><div>Henno</div></body></html>=
 
 --Apple-Mail-16-649696695--

From: Henno Schooljan <henno@schooljan.nl>
To: =?iso-8859-1?Q?Ulrich_Sp=F6rlein?= <uqs@spoerlein.net>,
        bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/135314: [zfs] assertion failed for zdb(8) usage
Date: Mon, 19 Oct 2009 22:05:34 +0200

 Found a difference after all:
 
 
 # zpool create tank /dev/ad4
 # zdb -i tank
 succeeds,
 # zfs get mountpoint tank
 gives:
 NAME  PROPERTY    VALUE       SOURCE
 tank  mountpoint  /tank       default
 
 
 
 # zpool create -m /tank tank /dev/ad4
 # zdb -i tank
 fails,
 # zfs get mountpoint tank
 gives:
 NAME  PROPERTY    VALUE       SOURCE
 tank  mountpoint  /tank       local
 
 Default vs. local. Gonna look into it further.
>Unformatted:
