Date: Mon, 09 Feb 2009 10:04:28 +0100 From: Michael Gusek <michael.gusek@web.de> To: freebsd-current@freebsd.org Subject: Re: zfs: allocating allocated segment Message-ID: <498FF19C.7000303@web.de> In-Reply-To: <498D6824.8060303@web.de> References: <200902051224.34442.michael.gusek@web.de> <20090206232327.GA19383@hyperion.scode.org> <498D6824.8060303@web.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Michael Gusek schrieb: > Peter Schuller schrieb: >>> I'm running a File server with zfs, 64 Bit, 4 GB Ram and RELENG_7. >>> Two days ago i uploaded a file via ftp to the server and the server >>> is crashing. After reboot FreeBSD can't import the zfs-pool. There >>> is a kernel-message: >>> >>> panic: Solaris(panic): zfs: allocating allocated >>> segment(offset=123456... size=74) >>> >>> cpuid = 0 >>> Uptime: 14m22s >>> panic: bufwrite: buffer is not busy??? >>> >>> Now i try to import the zfs-pool with a recent 8.0-current but with >>> the same result. It's very important to me to access the pool, so >>> did you have some idea's ? >>> >> >> The ZFS panic is from space_map.c in space_map_add(), happening via >> zfs_panic_recover(). It in turn is affected by zfs_recover: >> >> /* >> * zfs_recover can be set to nonzero to attempt to recover >> from >> * otherwise-fatal errors, typically caused by on-disk corruption. >> When >> * set, calls to zfs_panic_recover() will turn into warning >> messages. >> */ >> >> Setting the vfs.zfs.recover loader variable to 1 might possibly >> help. However I have never tried using that option and I'm not >> familiar with the code, so I have no idea how safe it is. In >> particular since you then seem to be getting a secondary panic (the >> "buffer is not busy" which is from ffs_vfsops. >> >> On another note: >> >> http://www.google.com/search?client=opera&rls=en&q=zfs:+allocating+allocated+segment&sourceid=opera&ie=utf-8&oe=utf-8 >> >> >> indicates you're not the only person who has seen similar >> errors. Unfortunately I cannot offer any insight other than to suggest >> digging through the google results. >> >> Was the original crash, prior to the mount problem, purely a software >> crash or was there, for example, a power outtage? I'm wondering >> whether there is any particular reason to believe there was some >> hardware/firmware fault causing corruption. >> >> > Thank you for your response Petter, > > on Monday i will give vfs.zfs.recover a try. The original crash was > beeing a ftp upload. There was'nt a power outtage or another kernel > message, so i don't think it is an hardware issue. > > Regards, > > Michael So now i'm trying set vfs.zfs.recover to 1. But the kernel crashed with panic: solaris assert: sm->sm_space == space (0xxfceee400 == 0xfceefc00) file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/space_map.c, line: 357 I't seems the zfs structure is corrupt ? And then, is there a chance to repair this ? Greetings, Michael
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?498FF19C.7000303>