Date: Mon, 29 Apr 2019 05:52:36 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 237637] ZFS kernel panic after removing a vdev Message-ID: <bug-237637-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237637 Bug ID: 237637 Summary: ZFS kernel panic after removing a vdev Product: Base System Version: 11.2-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: thalunil@kallisti.at Hi, on FreeBSD 11.2-RELEASE-p9 i removed a vdev on a ZFS pool, ZFS then started with "evacuating" the data on this device and proceeded for 40mins. When zpool status reported 100% the system panicked and rebooted. According to man 7 zpool-features device_removal is supported. Current zpool status (after invoking the kernel immediately crashes): pool: zfspool state: ONLINE scan: scrub repaired 0 in 4h10m with 0 errors on Sat Mar 16 23:39:35 2019 remove: Removal of vdev 4 copied 49.9G in 0h40m, completed on Sun Apr 21 21:01:31 2019 1.49M memory used for removed device mappings config: NAME STATE READ WRITE CKSUM zfspool ONLINE 0 0 0 da1 ONLINE 0 0 0 da2 ONLINE 0 0 0 da0 ONLINE 0 0 0 errors: No known data errors Example kernel panic: ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x0 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff8246e994 stack pointer =3D 0x28:0xfffffe02384547e0 frame pointer =3D 0x28:0xfffffe0238454810 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 0 (zio_free_issue_6_6) trap number =3D 12 panic: page fault cpuid =3D 0 KDB: stack backtrace: #0 0xffffffff80b3d5b7 at kdb_backtrace+0x67 #1 0xffffffff80af6b57 at vpanic+0x177 #2 0xffffffff80af69d3 at panic+0x43 #3 0xffffffff80f77fdf at trap_fatal+0x35f #4 0xffffffff80f78039 at trap_pfault+0x49 #5 0xffffffff80f77807 at trap+0x2c7 #6 0xffffffff80f580cc at calltrap+0x8 #7 0xffffffff824e81d7 at vdev_indirect_io_start_cb+0x37 #8 0xffffffff824e7e58 at vdev_indirect_remap+0x2f8 #9 0xffffffff824e7b3d at vdev_indirect_io_start+0x2d #10 0xffffffff82512cae at zio_vdev_io_start+0x2ae #11 0xffffffff8250f75c at zio_execute+0xac #12 0xffffffff8250f07b at zio_nowait+0xcb #13 0xffffffff824eb8ef at vdev_mirror_io_start+0x3ff #14 0xffffffff82512b62 at zio_vdev_io_start+0x162 #15 0xffffffff8250f75c at zio_execute+0xac #16 0xffffffff80b4edc4 at taskqueue_run_locked+0x154 #17 0xffffffff80b4ff28 at taskqueue_thread_loop+0x98 Uptime: 5d9h32m23s Dumping 719 out of 8157 MB:..3%..12%..21%..32%..41%..52%..61%..72%..81%..92% Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... Expected behaviour after device removal would be to have a usable, albeit reduced-size ZFS pool. thanks thal --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-237637-227>