ZFS snapshot problem

[Niki Denev]

On Feb 17, 2008 11:52 AM, Niki Denev <nike_d at cytexbg.com> wrote:
> I started seeing this in the last few days :
>
> # zfs list | grep zfs2/backups
> zfs2/backups                    759M   454G   747M  /zfs2/backups
> zfs2/backups at 16-02-08          11.9M      -   747M  -
> zfs2/backups at 17-02-08              0      -   747M  -
>
> # ls -la /zfs2/backups/.zfs/
> ls: snapshot: Bad file descriptor
>
> And the snapshots seem inaccessible... Any ideas are appreciated.
>
> The machine is running 7.0-PRERELEASE from 02/02/08,
> and has 5 days uptime (the problem began 2 days ago, judging from my
> backup script mails)
>

Today when i tried to unmount  the zfs2/backups dataset (with zfs
umount zfs2/backups)
the machine crashed immediately.
Here is the panic msg and backtrace :
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0xc0
fault code              = supervisor write data, page not present
instruction pointer     = 0x8:0xffffffff804800d5
stack pointer           = 0x10:0xffffffffd7836980
frame pointer           = 0x10:0xffffffffd7836a20
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 70668 (zfs)
trap number             = 12
panic: page fault
cpuid = 0
Uptime: 6d20h24m55s
Physical memory: 2034 MB
Dumping 1538 MB: 1523 1507 1491 1475 1459 1443 1427 1411 1395 1379
1363 1347 1331 1315 1299 1283 1267 1251 1235 1219 1203 1187 1171 1155
1139 1123 1107 1091 1075 1059 1043 1027 1011 995 979 963 947 931 915
899 883 867 851 835 819 803 787 771 755 739 723 707 691 675 659 643
627 611 595 579 563 547 531 515 499 483 467 451 435 419 403 387 371
355 339 323 307 291 275 259 243 227 211 195 179 163 147 131 115 99 83
67 51 35 19 3

#0  doadump () at pcpu.h:194
194     pcpu.h: No such file or directory.
        in pcpu.h

(kgdb) bt
#0  doadump () at pcpu.h:194
#1  0x0000000000000004 in avl_balance2child ()
#2  0xffffffff80478619 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:409
#3  0xffffffff80478a1d in panic (fmt=0x104 <Address 0x104 out of bounds>)
    at /usr/src/sys/kern/kern_shutdown.c:563
#4  0xffffffff8074f154 in trap_fatal (frame=0xffffff00015526a0,
eva=18446742976121881704)
    at /usr/src/sys/amd64/amd64/trap.c:724
#5  0xffffffff8074f525 in trap_pfault (frame=0xffffffffd78368d0, usermode=0)
    at /usr/src/sys/amd64/amd64/trap.c:641
#6  0xffffffff8074fe68 in trap (frame=0xffffffffd78368d0) at
/usr/src/sys/amd64/amd64/trap.c:410
#7  0xffffffff80735ace in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:169
#8  0xffffffff804800d5 in _sx_xlock (sx=0xa0, opts=0,
    file=0xffffffff80c697f0
"/usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c",
line=1069) at atomic.h:142
#9  0xffffffff80c50b2a in zfsctl_umount_snapshots (vfsp=Variable
"vfsp" is not available.
)
    at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c:1069
#10 0xffffffff80c57978 in zfs_umount (vfsp=0xffffff00014f7ca0,
fflag=0, td=0xffffff00015526a0)
    at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:692
#11 0xffffffff804ebfce in dounmount (mp=0xffffff00014f7ca0, flags=0,
td=0xffffff00015526a0)
    at /usr/src/sys/kern/vfs_mount.c:1286
#12 0xffffffff804ec7b5 in unmount (td=0xffffff00015526a0,
uap=0xffffffffd7836be0)
    at /usr/src/sys/kern/vfs_mount.c:1182
#13 0xffffffff8074f7a7 in syscall (frame=0xffffffffd7836c70) at
/usr/src/sys/amd64/amd64/trap.c:852
#14 0xffffffff80735cdb in Xfast_syscall () at
/usr/src/sys/amd64/amd64/exception.S:290
#15 0x0000000800f1396c in ?? ()
Previous frame inner to this frame (corrupt stack?)

Seems quite similar if not the same as (and it is on the same machine)
 : http://lists.freebsd.org/pipermail/freebsd-fs/2008-February/004377.html


  --Niki