ZFS v28 recv panic
James R. Van Artsdalen
james-freebsd-fs2 at jrv.org
Wed Oct 6 05:05:28 UTC 2010
The following series of commands cause a kernel panic with pjd's 8/31
zfs v28 patches on svn 212080:
zpool create rec1 da3
zpool create rec2 da4
zfs create rec1/a
zfs create rec1/a/b
zfs snapshot -r rec1 at s1
zfs rename rec1/a/b rec1/c
zfs destroy -r rec1/a
zfs create rec1/a
zfs rename rec1/c rec1/a/d
zfs snapshot -r rec1 at s2
zfs send -R rec1 at s1 | zfs recv -dvuF rec2
zfs send -R -I @s1 rec1 at s2 | zfs recv -dvuF rec2
(this is an attempt to wreak havoc on zfs send/recv by having a child
dataset that is older than the parent, but it tickles a kernel bug
rather than the zfs recv code)
The textdump.tar file is available upon request. The panic string is:
solaris assert: vp->v_count == 1, file:
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c,
line: 4510
The kernel config file:
kraken:/root# cat /usr/src/sys/amd64/conf/BIGTEX
include GENERIC
ident BIGTEX
nodevice hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx
#options PRINTF_BUFR_SIZE=128
nodevice uhid # "Human Interface Devices"
options DEBUG_LOCKS
options DEBUG_VFS_LOCKS
kraken:/root#
-------------- next part --------------
include GENERIC
ident BIGTEX
nodevice hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx
#options PRINTF_BUFR_SIZE=128
nodevice uhid # "Human Interface Devices"
options DEBUG_LOCKS
options DEBUG_VFS_LOCKS
-------------- next part --------------
A non-text attachment was scrubbed...
Name: textdump.tar.1
Type: application/octet-stream
Size: 121856 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20101006/c20456cc/textdump.tar-0001.obj
More information about the freebsd-fs
mailing list