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.
Responsible Changed From-To: freebsd-bugs->freebsd-fs Over to maintainer(s).
I can reproduce this on 8.0-RC1 i386. On amd64 it works fine. Henno
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
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=
On 19 okt 2009, at 20:35, Ulrich Spörlein 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 tank). The 8.0-RC1 CD is using ZFS version 13. Henno=
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.
State Changed From-To: open->feedback Can you reproduce it on 8.0-RC1? It works for me.
Responsible Changed From-To: freebsd-fs->pjd I'll take this one.
State Changed From-To: feedback->closed Close this PR, as I was able to reproduce the problem on older system, but I cannot reproduce it on HEAD/8.0.