A few days ago I used fdisk -p, modified two slice types in the output and used it as fdisk "config file" with the intention to merely change the slice types on disk. As an extra service, fdisk "adjusted" the size of the last slice (ad0s3) for me, thus the last sectors of ad0s3f became unreachable and geli could no longer read the meta information. ad0s3f.eli is part of the following ZFS pool: fk_at_TP51 ~ $sudo zpool status tank pool: tank state: ONLINE scrub: scrub completed with 0 errors on Wed May 28 22:05:33 2008 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 ad0s3f.eli ONLINE 0 0 0 ad0s2.eli ONLINE 0 0 0 errors: No known data errors After fdisk's "adjustment" ad0s2.eli was still available, while ad0s3f.eli wasn't. This reproducible caused the following panic a few seconds after loading the zfs module: Unread portion of the kernel message buffer: panic: solaris assert: vdev_config_sync(rvd, txg) == 0, file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c, line: 3014 cpuid = 0 KDB: enter: panic panic: from debugger cpuid = 0 Uptime: 59s Physical memory: 998 MB Dumping 85 MB: 70 54 38 22 6 [...] (kgdb) where #0 doadump () at pcpu.h:196 #1 0xc05c2446 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc05c2673 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:572 #3 0xc04ab827 in db_panic (addr=Could not find the frame base for "db_panic". ) at /usr/src/sys/ddb/db_command.c:446 #4 0xc04ac1dc in db_command (last_cmdp=0xc08d4190, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:413 #5 0xc04ac2ea in db_command_loop () at /usr/src/sys/ddb/db_command.c:466 #6 0xc04adadd in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:228 #7 0xc05e97e6 in kdb_trap (type=3, code=0, tf=0xf3b10b24) at /usr/src/sys/kern/subr_kdb.c:534 #8 0xc08192eb in trap (frame=0xf3b10b24) at /usr/src/sys/i386/i386/trap.c:683 #9 0xc07feddb in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #10 0xc05e996a in kdb_enter (why=0xc085d1da "panic", msg=0xc085d1da "panic") at cpufunc.h:60 #11 0xc05c265c in panic (fmt=0xc552b214 "solaris assert: %s, file: %s, line: %d") at /usr/src/sys/kern/kern_shutdown.c:556 #12 0xc54edb91 in spa_sync (spa=Variable "spa" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3014 #13 0xc54f4aca in txg_sync_thread (arg=0xc4c56400) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c:331 #14 0xc05a63e4 in fork_exit (callout=0xc54f48e0 <txg_sync_thread>, arg=0xc4c56400, frame=0xf3b10d38) at /usr/src/sys/kern/kern_fork.c:812 #15 0xc07fee50 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 With both pool members unavailable the panic didn't occur: fk_at_TP51 ~ $sudo zpool status pool: tank state: FAULTED status: One or more devices could not be used because the label is missing or invalid. There are insufficient replicas for the pool to continue functioning. action: Destroy and re-create the pool from a backup source. see: http://www.sun.com/msg/ZFS-8000-5E scrub: none requested config: NAME STATE READ WRITE CKSUM tank FAULTED 0 0 0 corrupted data ad0s3f UNAVAIL 0 0 0 corrupted data ad0s2 UNAVAIL 0 0 0 corrupted data After disabling the corrupted pool, I was also unable to import any other: [My notes are incomplete, but I think I just used "zpool export tank" here.] fk_at_TP51 ~ $sudo zpool status no pools available fk_at_TP51 ~ $sudo zpool import sv120 Assertion failed: ((null)), function fd == 0, file /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_import.c, line 771. Abort trap: 6 (core dumped) I'm using FreeBSD 8.0-CURRENT #0: Tue May 27 21:38:01 CEST 2008 fk_at_TP51.local:/usr/obj/usr/src/sys/THINKPAD i386. Should I file a PR about this (the ZFS part)? Given that a fdisk hack with the offending "adjustment" code removed was able to get the whole ad0s3f back, I'm also wondering if it wouldn't make sense to provide fdisk with a "no adjustments, please" option? Fabian
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:31 UTC